MySQLSQL優化：關聯子查詢的局限性

 　　這是MySQL SQL優化的第三篇。公司某個業務系統頻繁拋出問題SQL，我們對此類SQL做了基本面統計：

　　此類SQL近期共執行了12次，最長一次花費480秒，最短286秒

　　t1表的rows有90多萬，始終會掃描這麼多不需要的數據

　　這是由於MySQL查詢優化器在處理相關子查詢方面存在局限性

　　MySQL總是會將相關的外層表壓到子查詢中，它認為這可以更高效地查找數據行。

　　如果是個小表，情況可能還不會引起我們注意，但是如果外層表示一個非常大的表，那麼這個查詢的性能會非常槽糕，

　　很不幸，我們的場景剛好應了後者

　　我們優化後的執行效果：

　　Good Luck!