一次神奇的 SQL 慢查詢經(jīng)歷！
Java技術(shù)棧
www.javastack.cn
關(guān)注閱讀更多優(yōu)質(zhì)文章
作者：dijia478
來(lái)源：www.cnblogs.com/dijia478/p/11550902.html
一、問(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字段上我是加了索引的，也用到了。使用方法見(jiàn)這篇《Explain 最完整總結(jié)》文章。
三、優(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)致查詢慢，但我給where條件的所有字段加上了組合索引，也還是沒(méi)用。
思路三：
既然group by慢，換distinct試試？？
臥槽？？？！！！
這是什么情況，瞬間這么快了？？！！！
雖然知道group by和distinct有很小的性能差距，但是真沒(méi)想到，差距居然這么大！！！
大發(fā)現(xiàn)啊！！
四、你以為這就結(jié)束了嗎
我是真的希望就這么結(jié)束了，那這個(gè)問(wèn)題就很簡(jiǎn)單的解決了，順便還自以為是的發(fā)現(xiàn)了一個(gè)新知識(shí)。關(guān)注公眾號(hào)Java技術(shù)棧回復(fù)面試，可以獲取我整理的 MySQL 及更多面試題答案。
但是！
這個(gè)bug轉(zhuǎn)給測(cè)試后，測(cè)試一測(cè)，居然還是30多秒！？這是什么情況！！？？？
我當(dāng)然是不信了，去測(cè)試電腦上執(zhí)行sql，還真是30多秒。。。
我又回我的電腦上，連接同一個(gè)數(shù)據(jù)庫(kù)，一執(zhí)行sql，0.8秒！？
什么情況，同一個(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秒，在navicat和服務(wù)器上直接執(zhí)行，都是30多秒。
那就是sqlyog的問(wèn)題了，現(xiàn)在也不清楚sqlyog是不是做什么優(yōu)化了，這個(gè)慢查詢的問(wèn)題還在解決中（我覺(jué)得問(wèn)題可能是出在mysql自身的參數(shù)上吧）。
這里只是記錄下這個(gè)坑，sqlyog執(zhí)行sql速度，和服務(wù)器執(zhí)行sql速度，在有的sql中差異巨大，并不可靠。
五、后續(xù)（還未解決）
感謝大家出謀劃策，我來(lái)回復(fù)下問(wèn)題進(jìn)展：
1.所謂的sqlyog查詢快，命令行查詢慢的現(xiàn)象，已經(jīng)找到原因了。是因?yàn)閟qlyog會(huì)在查詢語(yǔ)句后默認(rèn)加上limit 1000，所以導(dǎo)致很快。這個(gè)問(wèn)題不再糾結(jié)。
2.我已經(jīng)試驗(yàn)過(guò)的方法（都沒(méi)有用）：
①給app_account字段加索引。
②給sql語(yǔ)句后面加order by null。
③調(diào)整where條件里字段的查詢順序，有索引的放前面。
④給所有where條件的字段加組合索引。
⑤用子查詢的方式，先查where條件里的內(nèi)容，再去重。
測(cè)試環(huán)境和現(xiàn)網(wǎng)環(huán)境數(shù)據(jù)還是有點(diǎn)不一樣的，我貼一張現(xiàn)網(wǎng)執(zhí)行sql的圖（1分鐘。。。）：
六、最終解決方案
經(jīng)過(guò)@言楓大佬！的提醒，我確實(shí)發(fā)現(xiàn)，explain執(zhí)行計(jì)劃里，索引好像并沒(méi)有用到我創(chuàng)建的idx_end_time。
然后果斷在現(xiàn)網(wǎng)試了下，強(qiáng)制指定使用idx_end_time索引，結(jié)果只要0.19秒！
至此問(wèn)題解決，其實(shí)同事昨天也在懷疑，是不是這個(gè)表索引建的太多了，導(dǎo)致用的不對(duì)，原本用的是idx_org_id和idx_mvno_id。
現(xiàn)在強(qiáng)制指定idx_end_time就ok了！
最后再對(duì)比下改前后的執(zhí)行計(jì)劃：
改之前（查詢要1分鐘左右）：
改之后（查詢只要幾百毫秒）：
關(guān)注Java技術(shù)棧看更多干貨
