這期內(nèi)容當中小編將會給大家?guī)碛嘘Psql查詢中如何進行group by慢查詢優(yōu)化，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

發(fā)展壯大離不開廣大客戶長期以來的信賴與支持，我們將始終秉承“誠信為本、服務至上”的服務理念，堅持“二合一”的優(yōu)良服務模式，真誠服務每家企業(yè)，認真做好每個細節(jié)，不斷完善自我，成就企業(yè)，實現(xiàn)共贏。行業(yè)涉及發(fā)電機租賃等，在成都網(wǎng)站建設、成都營銷網(wǎng)站建設、WAP手機網(wǎng)站、VI設計、軟件開發(fā)等項目上具有豐富的設計經(jīng)驗。

一、問題背景

現(xiàn)網(wǎng)出現(xiàn)慢查詢，在500萬數(shù)量級的情況下，單表查詢速度在30多秒，需要對sql進行優(yōu)化，sql如下：

我在測試環(huán)境構造了500萬條數(shù)據(jù)，模擬了這個慢查詢。

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

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

二、看執(zhí)行計劃

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

三、優(yōu)化

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

思路一：

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

思路二：

where條件太復雜，沒索引，導致查詢慢，但其實哪怕where條件不動，只要把group by去掉，就非?？?。所以應該也不是where條件的問題。

思路三：

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

臥槽？？？！??！這是什么情況，瞬間這么快了？？?。?！

雖然知道group by和distinct有很小的性能差距，但是真沒想到，差距居然這么大?。。〈蟀l(fā)現(xiàn)啊?。?/p>

四、你以為這就結束了嗎

我是真的希望就這么結束了，那這個問題就很簡單的解決了，順便還自以為是的發(fā)現(xiàn)了一個新知識。

但是！

這個bug轉(zhuǎn)給測試后，測試一測，居然還是30多秒??？這是什么情況?。?？？？

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

我又回我的電腦上，連接同一個數(shù)據(jù)庫，一執(zhí)行sql，0.8秒??？

什么情況，同一個庫，同一個sql，怎么在兩臺電腦執(zhí)行的差距這么大！

后來直接在服務器上執(zhí)行：

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

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

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

是因為我用的SQLyog！

哎，現(xiàn)在發(fā)現(xiàn)了，只有用sqlyog執(zhí)行這個“優(yōu)化后”的sql會是0.8秒，在navcat和服務器上直接執(zhí)行，都是30多秒。

那就是sqlyog的問題了，現(xiàn)在也不清楚sqlyog是不是做什么優(yōu)化了，這個慢查詢的問題還在解決中（我覺得問題可能是出在MySQL自身的參數(shù)上吧）。

sqlyog執(zhí)行sql速度，和服務器執(zhí)行sql速度，在有的sql中差異巨大，并不可靠。

上述就是小編為大家分享的sql查詢中如何進行group by慢查詢優(yōu)化了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道。