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