記一次神奇的MySQL查詢經(jīng)歷，group by慢查詢優(yōu)化

本文來源于群友的真實案例，對部分 SQL 略作脫敏修改，整理成本文，希望對大家有所幫助！

「一、問題背景」

現(xiàn)網(wǎng)出現(xiàn)慢查詢，在 500 萬數(shù)據(jù)量的情況下，單表查詢速度在 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)化?。∠日f下，下面的思路都是沒用的。

「思路一：」

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

「思路二：」

where 條件太復雜，沒索引，導致查詢慢，但我給 where 條件的所有字段加上了組合索引，也還是沒用。

「思路三：」

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

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

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

「四、你以為這就結束了嗎」

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

但是！

這個 bug 轉給測試后，測試一測，居然還是 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 中差異巨大，并不可靠。

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

感謝大家群里討論出謀劃策，我來回復下問題進展：

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

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 分鐘。。。）：

「六、最終解決方案」

感謝群里的“言楓”大佬！

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

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

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

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

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

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

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