一、問題背景

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

成都創(chuàng)新互聯(lián)專注于興賓網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供興賓營銷型網(wǎng)站建設(shè)，興賓網(wǎng)站制作、興賓網(wǎng)頁設(shè)計、興賓網(wǎng)站官網(wǎng)定制、微信小程序服務(wù)，打造興賓網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供興賓網(wǎng)站排名全網(wǎng)營銷落地服務(wù)。

我在測試環(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慢，換distinct試試？？（這里就是本篇博客里說的神奇的地方了）。

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

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

四、你以為這就結(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中差異巨大，并不可靠。

五、后續(xù)（還未解決）

感謝大家在評論里出謀劃策，我來回復(fù)下問題進(jìn)展：

1.所謂的sqlyog查詢快，命令行查詢慢的現(xiàn)象，已經(jīng)找到原因了。是因為sqlyog會在查詢語句后默認(rèn)加上limit 1000，所以導(dǎo)致很快。這個問題不再糾結(jié)。

2.我已經(jīng)試驗過的方法（都沒有用）：

①給app_account字段加索引。

②給sql語句后面加order by null。

③調(diào)整where條件里字段的查詢順序，有索引的放前面。

④給所有where條件的字段加組合索引。

⑤用子查詢的方式，先查where條件里的內(nèi)容，再去重。

測試環(huán)境和現(xiàn)網(wǎng)環(huán)境數(shù)據(jù)還是有點不一樣的，我貼一張現(xiàn)網(wǎng)執(zhí)行sql的圖（1分鐘。）：

六、最終解決方案

感謝評論里42樓的@言楓大佬！

經(jīng)過你的提醒，我確實發(fā)現(xiàn)，explain執(zhí)行計劃里，索引好像并沒有用到我創(chuàng)建的idx_end_time。

然后果斷在現(xiàn)網(wǎng)試了下，強制指定使用idx_end_time索引，結(jié)果只要0.19秒！

至此問題解決，其實同事昨天也在懷疑，是不是這個表索引建的太多了，導(dǎo)致用的不對，原本用的是idx_org_id和idx_mvno_id。

現(xiàn)在強制指定idx_end_time就ok了！

最后再對比下改前后的執(zhí)行計劃：

改之前（查詢要1分鐘左右）：

改之后（查詢只要幾百毫秒）：

網(wǎng)頁題目：記一次神奇的SQL查詢經(jīng)歷，groupby慢查詢優(yōu)化
網(wǎng)站網(wǎng)址：http://uogjgqi.cn/article/cdjhspp.html