回忆今天一段SQL优化场景

由于手头没有现场SQL代码，只能回忆回忆，顺便总结总结。

那段SQL的问题是执行时间很慢，left join了5张表当然慢了，其中四张表都是数据量很大的表，而且有一个在一个in()中写了一段很长的select。首先就把这个in()操作去掉了，修改了一下分页规则，这么一改立马就快了不少。但是页面响应超时是30秒还是超过啊，还要继续优化。5个left join通过一个一个的注释。。。。。嗯然后找到了最耗时间的那个join，把它注释掉就是秒查，加上它就变慢了，这样优化范围缩小了一大圈。观察发现这个left join有点特殊，on后面跟了两个条件，网上一百度果然on后面多条件会影响速度，可是也不能干掉啊，就建索引，建完索引快了一两秒吧。。。。。。然后经同事提醒其中一个条件a.seqid = b.person_seqid这两个字段类型不同，一个是int型一个是long型，这样关联需要有一个类型转换的过程，数据量又大所以会慢。最后选了一个符合条件的同类型的字段关联，果然问题解决了，秒查。

没有SQL就这么说确实比较抽象。

---------分割线---------

后来发现对on后面的多条件建立组合索引，会大大提高查询速度。