現網出現慢查詢，在500萬數量級的情況下，單表查詢速度在30多秒，需要對sql進行優化，sql如下：

我在測試環境構造了500萬條資料，模擬了這個慢查詢。

簡單來說，就是查詢一定條件下，都有哪些使用者的。很簡單的sql，可以看到，查詢耗時為37秒。

說一下app_account欄位的分佈情況，隨機生成了5000個不同的隨機數，然後分佈到了這500萬條資料裡，平均來說，每個app_account都會有1000個是重複的值，種類共有5000個。

二、看執行計劃

可以看到，group by欄位上我是加了索引的，也用到了。

三、優化

說實話，我是不知道該怎麼優化的，這玩意還能怎麼優化啊！先說下，下面的思路都是沒用的。

後面應該加上 order by null；避免無用排序，但其實對結果耗時影響不大，還是很慢。

where條件太複雜，沒索引，導致查詢慢，但我給where條件的所有欄位加上了組合索引，也還是沒用

思路三：

既然group by慢，換distinct試試？？（這裡就是本篇部落格裡說的神奇的地方了）

臥槽？？？！！！這是什麼情況，瞬間這麼快了？？！！！

雖然知道group by和distinct有很小的效能差距，但是真沒想到，差距居然這麼大！！！大發現啊！！

四、你以為這就結束了嗎

我是真的希望就這麼結束了，那這個問題就很簡單的解決了，順便還自以為是的發現了一個新知識。

但是！

這個bug轉給測試後，測試一測，居然還是30多秒！？這是什麼情況！！？？？

我當然是不信了，去測試電腦上執行sql，還真是30多秒。。。

我又回我的電腦上，連線同一個資料庫，一執行sql，0.8秒！？

什麼情況，同一個庫，同一個sql，怎麼在兩臺電腦執行的差距這麼大！

後來直接在伺服器上執行：

醉了，居然還是30多秒。。。。

那看來就是我電腦的問題了。

後來我用多個同事的電腦實驗，最後得出的結論是：

是因為我用的SQLyog！

哎，現在發現了，只有用sqlyog執行這個“優化後”的sql會是0.8秒，在navcat和伺服器上直接執行，都是30多秒。

那就是sqlyog的問題了，現在也不清楚sqlyog是不是做什麼優化了，這個慢查詢的問題還在解決中（我覺得問題可能是出在mysql自身的引數上吧）。

這裡只是記錄下這個坑，sqlyog執行sql速度，和伺服器執行sql速度，在有的sql中差異巨大，並不可靠。

五、後續（還未解決）

1.所謂的sqlyog查詢快，命令列查詢慢的現象，已經找到原因了。是因為sqlyog會在查詢語句後預設加上limit 1000，所以導致很快。這個問題不再糾結。

2.我已經試驗過的方法（都沒有用）：

①給app_account欄位加索引。

②給sql語句後面加order by null。

④給所有where條件的欄位加組合索引。

⑤用子查詢的方式，先查where條件裡的內容，再去重。

測試環境和現網環境資料還是有點不一樣的，我貼一張現網執行sql的圖（1分鐘。。。）：

六、最終解決方案

經過你的提醒，我確實發現，explain執行計劃裡，索引好像並沒有用到我建立的idx_end_time。

然後果斷在現網試了下，強制指定使用idx_end_time索引，結果只要0.19秒！

至此問題解決，其實同事昨天也在懷疑，是不是這個表索引建的太多了，導致用的不對，原本用的是idx_org_id和idx_mvno_id。

現在強制指定idx_end_time就ok了！

最後再對比下改前後的執行計劃

改之前（查詢要1分鐘左右）：

改之後（查詢只要幾百毫秒）：

關注小編，更多幹貨奉上！