您好,登錄后才能下訂單哦!
小編今天帶大家了解如何實現group by慢查詢優化,文中知識點介紹的非常詳細。覺得有幫助的朋友可以跟著小編一起瀏覽文章的內容,希望能夠幫助更多想解決這個問題的朋友找到問題的答案,下面跟著小編一起深入學習“如何實現group by慢查詢優化”的知識吧。
現網出現慢查詢,在500萬數量級的情況下,單表查詢速度在30多秒,需要對sql進行優化,sql如下:
我在測試環境構造了500萬條數據,模擬了這個慢查詢。
簡單來說,就是查詢一定條件下,都有哪些用戶的。很簡單的sql,可以看到,查詢耗時為37秒。
說一下app_account字段的分布情況,隨機生成了5000個不同的隨機數,然后分布到了這500萬條數據里,平均來說,每個app_account都會有1000個是重復的值,種類共有5000個。
二、看執行計劃
可以看到,group by字段上我是加了索引的,也用到了。
三、優化
說實話,我是不知道該怎么優化的,這玩意還能怎么優化啊!先說下,下面的思路都是沒用的。
后面應該加上 order by null;避免無用排序,但其實對結果耗時影響不大,還是很慢。
where條件太復雜,沒索引,導致查詢慢,但我給where條件的所有字段加上了組合索引,也還是沒用
既然group by慢,換distinct試試??(這里就是本篇博客里說的神奇的地方了)
臥槽???!!!這是什么情況,瞬間這么快了??!!!
雖然知道group by和distinct有很小的性能差距,但是真沒想到,差距居然這么大!!!大發現啊!!
四、你以為這就結束了嗎
我是真的希望就這么結束了,那這個問題就很簡單的解決了,順便還自以為是的發現了一個新知識。
但是!
這個bug轉給測試后,測試一測,居然還是30多秒!?這是什么情況!!???
我當然是不信了,去測試電腦上執行sql,還真是30多秒。。。
我又回我的電腦上,連接同一個數據庫,一執行sql,0.8秒!?
什么情況,同一個庫,同一個sql,怎么在兩臺電腦執行的差距這么大!
后來直接在服務器上執行:
醉了,居然還是30多秒。。。。
那看來就是我電腦的問題了。
后來我用多個同事的電腦實驗,最后得出的結論是:
是因為我用的SQLyog!
哎,現在發現了,只有用sqlyog執行這個“優化后”的sql會是0.8秒,在navcat和服務器上直接執行,都是30多秒。
那就是sqlyog的問題了,現在也不清楚sqlyog是不是做什么優化了,這個慢查詢的問題還在解決中(我覺得問題可能是出在mysql自身的參數上吧)。
這里只是記錄下這個坑,sqlyog執行sql速度,和服務器執行sql速度,在有的sql中差異巨大,并不可靠。
五、后續(還未解決)
感謝大家出謀劃策,我來回復下問題進展:
1.所謂的sqlyog查詢快,命令行查詢慢的現象,已經找到原因了。是因為sqlyog會在查詢語句后默認加上limit 1000,所以導致很快。這個問題不再糾結。
2.我已經試驗過的方法(都沒有用):
①給app_account字段加索引。
②給sql語句后面加order by null。
③調整where條件里字段的查詢順序,有索引的放前面。
④給所有where條件的字段加組合索引。
⑤用子查詢的方式,先查where條件里的內容,再去重。
測試環境和現網環境數據還是有點不一樣的,我貼一張現網執行sql的圖(1分鐘。。。):
六、最終解決方案
感謝評論里42樓的@言楓大佬!
經過你的提醒,我確實發現,explain執行計劃里,索引好像并沒有用到我創建的idx_end_time。
然后果斷在現網試了下,強制指定使用idx_end_time索引,結果只要0.19秒!
至此問題解決,其實同事昨天也在懷疑,是不是這個表索引建的太多了,導致用的不對,原本用的是idx_org_id和idx_mvno_id。
現在強制指定idx_end_time就ok了!
最后再對比下改前后的執行計劃
改之前(查詢要1分鐘左右):
改之后(查詢只要幾百毫秒):
感謝大家的閱讀,以上就是“如何實現group by慢查詢優化”的全部內容了,學會的朋友趕緊操作起來吧。相信億速云小編一定會給大家帶來更優質的文章。謝謝大家對億速云網站的支持!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。