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中的字段順序無所謂，可以随便放在哪，應該盡可能地第一次就過濾掉大部分無用的資料，隻傳回最小範圍的資料。 希望能幫到有同樣遭遇的朋友。