?2016-2026 Matools All rights reserved,
粵ICP備17059708號
一、問題背景
現(xiàn)網(wǎng)出現(xiàn)慢查詢，在500萬數(shù)量級的情況下，單表查詢速度在30多秒，需要對sql進行優(yōu)化，sql如下：
我在測試環(huán)境構(gòu)造了500萬條數(shù)據(jù)，模擬了這個慢查詢。
簡單來說，就是查詢一定條件下，都有哪些用戶的。很簡單的sql，可以看到，查詢耗時為37秒。
說一下app_account字段的分布情況，隨機生成了5000個不同的隨機數(shù)，然后分布到了這500萬條數(shù)據(jù)里，平均來說，每個app_account都會有1000個是重復(fù)的值，種類共有5000個。
二、看執(zhí)行計劃
可以看到，group by字段上我是加了索引的，也用到了。
三、優(yōu)化
說實話，我是不知道該怎么優(yōu)化的，這玩意還能怎么優(yōu)化??！先說下，下面的思路都是沒用的。
思路一：
后面應(yīng)該加上 order by null；避免無用排序，但其實對結(jié)果耗時影響不大，還是很慢。
思路二：
where條件太復(fù)雜，沒索引，導(dǎo)致查詢慢，但其實哪怕where條件不動，只要把group by去掉，就非常快。所以應(yīng)該也不是where條件的問題。
思路三：
既然group by慢，換distinct試試？？（這里就是本篇博客里說的神奇的地方了）
臥槽？？？?。?！這是什么情況，瞬間這么快了？？?。?！
雖然知道group by和distinct有很小的性能差距，但是真沒想到，差距居然這么大?。?！大發(fā)現(xiàn)啊?。?br>
四、你以為這就結(jié)束了嗎
我是真的希望就這么結(jié)束了，那這個問題就很簡單的解決了，順便還自以為是的發(fā)現(xiàn)了一個新知識。
但是！
這個bug轉(zhuǎn)給測試后，測試一測，居然還是30多秒！？這是什么情況?。?？？？
我當(dāng)然是不信了，去測試電腦上執(zhí)行sql，還真是30多秒。。。
我又回我的電腦上，連接同一個數(shù)據(jù)庫，一執(zhí)行sql，0.8秒！？
什么情況，同一個庫，同一個sql，怎么在兩臺電腦執(zhí)行的差距這么大！
后來直接在服務(wù)器上執(zhí)行：
?醉了，居然還是30多秒。。。。
那看來就是我電腦的問題了。
后來我用多個同事的電腦實驗，最后得出的結(jié)論是：
是因為我用的SQLyog！
哎，現(xiàn)在發(fā)現(xiàn)了，只有用sqlyog執(zhí)行這個“優(yōu)化后”的sql會是0.8秒，在navcat和服務(wù)器上直接執(zhí)行，都是30多秒。
那就是sqlyog的問題了，現(xiàn)在也不清楚sqlyog是不是做什么優(yōu)化了，這個慢查詢的問題還在解決中（我覺得問題可能是出在mysql自身的參數(shù)上吧）。
這里只是記錄下這個坑，sqlyog執(zhí)行sql速度，和服務(wù)器執(zhí)行sql速度，在有的sql中差異巨大，并不可靠。
?
熱門工具 換一換