記一次神奇的sql查詢經歷，group by慢查詢優化（已解決）

1、問題背景

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

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

簡單來講，就是查詢必定條件下，都有哪些用戶的。很簡單的sql，能夠看到，查詢耗時爲37秒。

說一下app_account字段的分佈狀況，隨機生成了5000個不一樣的隨機數，而後分佈到了這500萬條數據裏，平均來講，每一個app_account都會有1000個是重複的值，種類共有5000個。

2、看執行計劃

能夠看到，group by字段上我是加了索引的，也用到了。

3、優化

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

思路一：

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

思路二：

where條件太複雜，沒索引，致使查詢慢，但我給where條件的全部字段加上了組合索引，也仍是沒用

思路三：

既然group by慢，換distinct試試？？（這裏就是本篇博客裏說的神奇的地方了）

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

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

4、你覺得這就結束了嗎

我是真的但願就這麼結束了，那這個問題就很簡單的解決了，順便還自覺得是的發現了一個新知識。

可是！

這個bug轉給測試後，測試一測，竟然仍是30多秒！？這是什麼狀況！！？？？

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

我又回個人電腦上，鏈接同一個數據庫，一執行sql，0.8秒！？

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

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

 醉了，竟然仍是30多秒。。。。

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

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

是由於我用的SQLyog！

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

那就是sqlyog的問題了，如今也不清楚sqlyog是否是作什麼優化了，這個慢查詢的問題還在解決中（我以爲問題多是出在mysql自身的參數上吧）。

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

 

5、後續（還未解決）

感謝你們在評論裏出謀劃策，我來回復下問題進展：

1.所謂的sqlyog查詢快，命令行查詢慢的現象，已經找到緣由了。是由於sqlyog會在查詢語句後默認加上limit 1000，因此致使很快。這個問題再也不糾結。

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

①給app_account字段加索引。

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

③調整where條件裏字段的查詢順序，有索引的放前面。

④給全部where條件的字段加組合索引。

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

 

測試環境和現網環境數據仍是有點不同的，我貼一張現網執行sql的圖（1分鐘。。。）：

6、最終解決方案

感謝評論裏42樓的@言楓大佬！

通過你的提醒，我確實發現，explain執行計劃裏，索引好像並無用到我建立的idx_end_time。

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

 

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

如今強制指定idx_end_time就ok了！

 

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

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

 

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