点赞图镇楼
起因是这样的，听产品经理阿强说公司那个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断定加入各自表并加入别名，
这样在关联时取消了很多不必要的笛卡尔积关联。
最近疫情隔离，提醒自己和各位一定要备好菜！
谢谢，如果感觉不错，点个赞再撤吧！
