這是MySQL SQL優化的第三篇。公司某個業務系統頻繁拋出問題SQL,我們對此類SQL做了基本面統計:
此類SQL近期共執行了12次,最長一次花費480秒,最短286秒
t1表的rows有90多萬,始終會掃描這麼多不需要的數據
這是由於MySQL查詢優化器在處理相關子查詢方面存在局限性
MySQL總是會將相關的外層表壓到子查詢中,它認為這可以更高效地查找數據行。
如果是個小表,情況可能還不會引起我們注意,但是如果外層表示一個非常大的表,那麼這個查詢的性能會非常槽糕,
很不幸,我們的場景剛好應了後者
我們優化後的執行效果:
Good Luck!