記一次神奇的sql查詢經歷,group by慢查詢優化
一、問題背景
現網出現慢查詢,在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中差異巨大,並不可靠。