点赞图镇楼
起因是这样的,听产品经理阿强说公司那个SQL疑难杂症挺久了,某哥没有修复好,想让我看看。
昨日早晨开会,通过WX语音和接收到的相关业务文档,数据库表名,我大概有所了解,
下拉了代码,一看!哦豁!
大大小小的查询方法,在一个接口方法里,居然有几十条之多!
我无奈之下,想起前天看的SQL执行计划,心想就先排查一下哪个SQL语句最拉垮吧!
在几十条的SQL mapper查询语句中,通过执行时间,我定位到一条语句执行要27秒之久,
这与其他的执行语句短则几百毫秒,长则1秒是有很大区别的,整体接口的执行时间也是30+-秒,
所以我就首先要看这个27s语句的问题。
打开数据库发现这条语句关联到的表有3个,
分别是订单表,商品表,还有一个类似什么关联表,不管了,我看数据量吧。
通过执行计划看这条语句关联到的数据量最多的有一个表,其中数据量关系到百万级别。
然后我看这个表相关的where语句关系到的列是否加了索引,
没加?我加上,当然其它另外两个表也都按照索引添加原理进行了增加。
最后我再执行,还是差强人意,通过执行计划一看,有的索引没有使用到。
通过对SQL语句的关联以及where最终用到的几个字段,
我又添加了联合索引,
ok!奏效了!而有时问题比较繁琐时,
我在select ... from tableA 后加入 force index(指定的索引名)
去调试,果然是要选择那个执行最快的索引才可以,
!!!并不是一个表用到的索引越多就查询越快哦!!!
联合索引的增加,我也是按照先where再关联on最终外层where的顺序增加的
当不force index强制使用这个联合索引时,通过执行计划看到,
也是使用的这个联合索引哦,而且速度是最快的,
在数据量关联最多的那个表,可能使用单一或几个索引有明显的优势,
比如range区间查询时,指定where .. in的字段,会提升超级大
同时在多表关联时,将能加入各自表的where断定加入各自表并加入别名,
这样在关联时取消了很多不必要的笛卡尔积关联。
最近疫情隔离,提醒自己和各位一定要备好菜!
谢谢,如果感觉不错,点个赞再撤吧!