作者：dijia478

來源：https://www.cnblogs.com/dijia478/p/11550902.html

一、問題背景

現網出現慢查詢，在500萬數量級的情況下，單表查詢速度在30多秒，需要對sql進行優(yōu)化，sql如下：我在測試環(huán)境構造了500萬條數據，模擬了這個慢查詢。簡單來說，就是查詢一定條件下，都有哪些用戶的。很簡單的sql，可以看到，查詢耗時為37秒。說一下app_account字段的分布情況，隨機生成了5000個不同的隨機數，然后分布到了這500萬條數據里，平均來說，每個app_account都會有1000個是重復的值，種類共有5000個。

二、看執(zhí)行計劃

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

三、優(yōu)化

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

思路一：

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

思路二：

where條件太復雜，沒索引，導致查詢慢，但我給where條件的所有字段加上了組合索引，也還是沒用。搜索并關注微信公眾號碼匠筆記回復面試，獲取經典面試資料匯總。

思路三：

既然group by慢，換distinct試試？？(這里就是本篇博客里說的神奇的地方了)臥槽？？？！！！這是什么情況，瞬間這么快了？？！！！雖然知道group by和distinct有很小的性能差距，但是真沒想到，差距居然這么大！！！大發(fā)現啊！！

四、你以為這就結束了嗎

我是真的希望就這么結束了，那這個問題就很簡單的解決了，順便還自以為是的發(fā)現了一個新知識。但是！這個bug轉給測試后，測試一測，居然還是30多秒！？這是什么情況！！？？？我當然是不信了，去測試電腦上執(zhí)行sql，還真是30多秒。。。我又回我的電腦上，連接同一個數據庫，一執(zhí)行sql，0.8秒！？什么情況，同一個庫，同一個sql，怎么在兩臺電腦執(zhí)行的差距這么大！后來直接在服務器上執(zhí)行：醉了，居然還是30多秒。。。。那看來就是我電腦的問題了。后來我用多個同事的電腦實驗，最后得出的結論是：是因為我用的SQLyog！哎，現在發(fā)現了，只有用sqlyog執(zhí)行這個“優(yōu)化后”的sql會是0.8秒，在navcat和服務器上直接執(zhí)行，都是30多秒。那就是sqlyog的問題了，現在也不清楚sqlyog是不是做什么優(yōu)化了，這個慢查詢的問題還在解決中(我覺得問題可能是出在mysql自身的參數上吧)。這里只是記錄下這個坑，sqlyog執(zhí)行sql速度，和服務器執(zhí)行sql速度，在有的sql中差異巨大，并不可靠。搜索并關注微信公眾號碼匠筆記回復面試，獲取經典面試資料匯總。

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

感謝大家出謀劃策，我來回復下問題進展：1.所謂的sqlyog查詢快，命令行查詢慢的現象，已經找到原因了。是因為sqlyog會在查詢語句后默認加上limit 1000，所以導致很快。這個問題不再糾結。2.我已經試驗過的方法(都沒有用)：①給app_account字段加索引。②給sql語句后面加order by null。③調整where條件里字段的查詢順序，有索引的放前面。④給所有where條件的字段加組合索引。⑤用子查詢的方式，先查where條件里的內容，再去重。測試環(huán)境和現網環(huán)境數據還是有點不一樣的，我貼一張現網執(zhí)行sql的圖(1分鐘。。。)：

六、最終解決方案

感謝評論里42樓的@言楓大佬！經過你的提醒，我確實發(fā)現，explain執(zhí)行計劃里，索引好像并沒有用到我創(chuàng)建的idx_end_time。然后果斷在現網試了下，強制指定使用idx_end_time索引，結果只要0.19秒！至此問題解決，其實同事昨天也在懷疑，是不是這個表索引建的太多了，導致用的不對，原本用的是idx_org_id和idx_mvno_id。現在強制指定idx_end_time就ok了！最后再對比下改前后的執(zhí)行計劃改之前(查詢要1分鐘左右)：改之后(查詢只要幾百毫秒)：

特別推薦一個分享架構+算法的優(yōu)質內容，還沒關注的小伙伴，可以長按關注一下：

長按訂閱更多精彩▼

如有收獲，點個在看，誠摯感謝

總結

以上是生活随笔為你收集整理的怎么会执行sql 懒加载 没用_太神奇的 SQL 查询经历，group by 慢查询优化！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。