一、問題背景

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

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

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

說一下App_account字段的分布情況，隨機生成了5000個不同的隨機數，然后分布到了這500萬條數據里，平均來說，每個app_account都會有1000個是重復的值，種類共有5000個。

二、看執行計劃

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

三、優化

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

思路一：

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

思路二：

where條件太復雜，沒索引，導致查詢慢，但其實哪怕where條件不動，只要把group by去掉，就非常快。所以應該也不是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中差異巨大，并不可靠。