sql查詢中如何進(jìn)行g(shù)roup by慢查詢優(yōu)化

這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)sql查詢中如何進(jìn)行g(shù)roup by慢查詢優(yōu)化，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

一、問(wèn)題背景

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

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

簡(jiǎn)單來(lái)說(shuō)，就是查詢一定條件下，都有哪些用戶的。很簡(jiǎn)單的sql，可以看到，查詢耗時(shí)為37秒。

說(shuō)一下app_account字段的分布情況，隨機(jī)生成了5000個(gè)不同的隨機(jī)數(shù)，然后分布到了這500萬(wàn)條數(shù)據(jù)里，平均來(lái)說(shuō)，每個(gè)app_account都會(huì)有1000個(gè)是重復(fù)的值，種類共有5000個(gè)。

二、看執(zhí)行計(jì)劃

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

三、優(yōu)化

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

思路一：

后面應(yīng)該加上 order by null；避免無(wú)用排序，但其實(shí)對(duì)結(jié)果耗時(shí)影響不大，還是很慢。

思路二：

where條件太復(fù)雜，沒(méi)索引，導(dǎo)致查詢慢，但其實(shí)哪怕where條件不動(dòng)，只要把group by去掉，就非?？?。所以應(yīng)該也不是where條件的問(wèn)題。

思路三：

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

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

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

四、你以為這就結(jié)束了嗎

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

但是！

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

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

我又回我的電腦上，連接同一個(gè)數(shù)據(jù)庫(kù)，一執(zhí)行sql，0.8秒?。?/p>

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

后來(lái)直接在服務(wù)器上執(zhí)行：

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

那看來(lái)就是我電腦的問(wèn)題了。

后來(lái)我用多個(gè)同事的電腦實(shí)驗(yàn)，最后得出的結(jié)論是：

是因?yàn)槲矣玫腟QLyog！

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

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

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

上述就是小編為大家分享的sql查詢中如何進(jìn)行g(shù)roup by慢查詢優(yōu)化了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注億速云行業(yè)資訊頻道。