MySQL:联合索引与Where子句的优化

在群友的分析指点下，尝试把排序、条件等一个一个去除来做测试，结果发现问题就出在排序部分，去除排序的时候，执行时间由原来的48秒变成0.3x秒，这是个什么档次的变化呀~~看着这个结果我激动ing.....

于是我把涉及排序的字段组成一个联合索引alter table xx add index indexname(x1,x2,x3)，经过2分钟创建新索引之后再执行同一个sql语句，哇塞0.28s。。。。爽

比如你需要

where col1=??? and col2=???

则建议创建索引 (col1,col2)

如果你要 where col1=?? order by col3

则建议创建索引 (col1,col3)

于是按照同样的思路把其它几个常用的sql作了过些优化，效果马上见效

过了30分钟再查slow sql记录文件，不好了，发现原来一个好好的sql变得灰常慢了，神马情况?

几经分析和测试原来就是因为添加了联合索引的原因，而且这个sql语句当中有个or，当把这个or改用union之后问题排除。

这回又得出一个心得：写sql的时候千万别一时就手，随便写个就ok，那会为以为带来很严重的后果。

再附上一段关于where子句的执行顺序：

select ... where p.languages_id = 1 and m.languages_id = 1 and c.languages_id = 1 and t.languages_id = 1 and p.products_id in (472,474)  

 这样查询需要20多秒，虽然在各个字段上都建立了索引。用分析explain sql一分析，发现在第一次分析过程中就返回了几万条数据：

where p.languages_id = 1 ，然后再依次根据条件，缩小范围。

而我改变一下where 字段的位置之后，速度就有了明显地提高：

where p.products_id in (472,474) and p.languages_id = 1 and m.languages_id = 1 and c.languages_id = 1 and t.languages_id = 1  

这样，第一次的条件是p.products_id in (472,474)，它返回的结果只有不到10条，接下来还要根据其它的条件来过滤，自然在速度上有了较大的提升。

经过实践发现，不要以为where中的字段顺序无所谓，可以随便放在哪，应该尽可能地第一次就过滤掉大部分无用的数据，只返回最小范围的数据。 希望能帮到有同样遭遇的朋友。