我：嗨，老闆娘，有冰紅茶沒
老闆娘：有
我：多少錢一瓶
老闆娘：3塊
我：給我來一瓶，給，3塊
老闆娘：來，你的冰紅茶
我：玩呐，我要冰紅茶，你給我個瓶蓋幹哈？
老闆娘：這是再來一瓶，我家賣完了，你去隔壁家換一下
對于 MySQL 的 JOIN，不知道大家有沒有去想過他的執行流程，亦或有沒有懷疑過自己的了解（自信滿滿的自我認為！）；如果大家不知道怎麼檢驗，可以試着回答如下的問題
MySQL 會如何選擇驅動表，按從左至右的順序選擇第一個？
假設我們有 3 張表：A、B、C，和如下 SQL
是 A 和 B 聯表處理完之後的結果再和 C 進行聯表處理，還是 A、B、C 一起聯表之後再進行過濾處理 ，還是說這兩種都不對，有其他的處理方式 ？
樓主無意之間逛到了一篇博文，它裡面有如下介紹
正經圖1 摘自 Mysql - JOIN詳解
看完這個，樓主第一時間有發現新大陸的感覺，原來 JOIN 的執行順序是這樣的（不是颠覆了樓主之前的認知，因為樓主之前就沒想過這個問題，而是有種新技能擷取的滿足），可後面越想越不對，感覺像是學錯了技能（6級沒學大！）
如果兩表各有幾百上千萬的資料，那這兩張表做笛卡爾積，結果不敢想象！也就是說 正經圖1 中的順序還有待商榷，ON 和 WHERE 的生效時間也有待商榷
如果你對上述問題都了如指掌，那請你走開，别妨礙我裝逼；如果你對上述問題還不是特别清楚，那麼請坐好，我要開始裝逼了
正式開講之前了，先給大家預備一些花生、瓜子和啤酒，裝逼就得有裝逼的氛圍，不然怎麼看的下去，你說是吧 ？（樓主，你個騙子，貨了？）
何謂驅動表，指多表關聯查詢時，第一個被處理的表，亦可稱之為基表，然後再使用此表的記錄去關聯其他表。驅動表的選擇遵循一個原則：在對最終結果集沒影響的前提下，優先選擇結果集最少的那張表作為驅動表。這個原則說的不好懂，結果集最少，這個也許我們能估出來，但對最終結果集不影響，這個就不好判斷了，難歸難，但還是有一定規律的：
LEFT JOIN 某些情況下會被查詢優化器優化成 INNER JOIN；結果集指的是表中記錄過濾後的結果，而不是表中的所有記錄，如果無過濾條件則是表中所有記錄
更多資訊可檢視：Mysql多表連接配接查詢的執行細節（一）
當我們向 MySQL 發送一個請求的時候，MySQL 到底做了些了什麼
SQL 執行路徑，摘自《高性能MySQL》
可以看到，執行計劃是查詢優化器的輸出結果，執行引擎根據執行計劃來查詢資料
MySQL 5.7.1，InnoDB 引擎；建表 SQL 和 資料初始 SQL
View Code
單表查詢的過程比較好了解，大緻如下
關于單表查詢就不細講了，主要涉及到：聚簇索引，覆寫索引、回表操作，知道這 3 點，上圖就好了解了（不知道的趕快去查資料，暴露了就丢人了！）。
MySQL 的聯表算法是基于嵌套循環算法（nested-loop algorithm）而衍生出來的一系列算法，根據不同條件而選用不同的算法
簡單嵌套循環，簡稱 SNL；逐條逐條比對，就像這樣
這種算法簡單粗暴，但毫無性能可言，時間性能上來說是 n（表中記錄數） 的 m（表的數量） 次方，是以 MySQL 做了優化，聯表查詢的時候不會出現這種算法，即使在無 WHERE 條件且 ON 的連接配接鍵上無索引時，也不會選用這種算法
緩存塊嵌套循環連接配接，簡稱 BNL，是對 SNL 的一種優化；一次性緩存多條驅動表的資料到 Join Buffer，然後拿 Join Buffer 裡的資料批量與内層循環讀取的資料進行比對，就像這樣
将内部循環中讀取的每一行與緩沖區中的所有記錄進行比較，這樣就可以減少内層循環的讀表次數。舉個例子，如果沒有 Join Buffer，驅動表有 30 條記錄，被驅動表有 50 條記錄，那麼内層循環的讀表次數應該是 30 * 50 = 1500，如果 Join Buffer 可用并可以存 10 條記錄（Join Buffer 存儲的是驅動表中參與查詢的列，包括 SELECT 的列、ON 的列、WHERE 的列，而不是驅動表中整行整行的完整記錄），那麼内層循環的讀表次數應該是 30 / 10 * 50 = 150，被驅動表必須讀取的次數減少了一個數量級。
當被驅動表在連接配接鍵上無索引且被驅動表在 WHERE 過濾條件上也沒索引時，常常會采用此種算法來完成聯表，如下所示
索引嵌套循環，簡稱 INL，是基于被驅動表的索引進行連接配接的算法；驅動表的記錄逐條與被驅動表的索引進行比對，避免和被驅動表的每條記錄進行比較，減少了對被驅動表的比對次數，大緻流程如下圖
我們來看看實際案例，先給 tbl_user_login_log 添加索引 ALTER TABLE tbl_user_login_log ADD INDEX idx_user_name (user_name); ，我們再來看聯表執行計劃
可以看到 tbl_user_login_log 的索引生效了，我們再往下看
有趣的事發生了，驅動表變成了 tbl_user_login_log ，而 tbl_user 成了被驅動表， tbl_user_login_log 走索引過濾後得到結果集，再通過 BNL 算法将結果集與 tbl_user 進行比對。這其實是 MySQL進行了優化，因為 tbl_user_login_log 走索引過濾後得到的結果集比 tbl_user 記錄數要少，是以選擇了 tbl_user_login_log 作為驅動表，後面的也就理所當然了，是不是感覺 MySQL 好強大？
批量key通路，簡稱 BKA，是對 INL 算法的一種優化；
BKA 對 INL 的優化類似于 BNL 對 SNL 的優化，但又有不同； 鑒于篇幅原因，BKA 我們放到下期講解，希望各位老哥見諒！實在是不行，你來打我呀！
1、驅動表的選擇有它的一套算法，有興趣的可以去專研下；比較靠譜的确定方法是用 EXPLAIN
2、聯表順序，不是兩兩聯合之後，再去聯合第三張表，而是驅動表的一條記錄穿到底，比對完所有關聯表之後，再取驅動表的下一條記錄重複聯表操作；
3、MySQL 的連接配接算法基于嵌套循環算法，基于不同的情況而采用不同的衍生算法
4、關于 ON 和 WHERE，我們下篇詳細講解，大家可以先考慮下它們的差別，以及生效時間
Mysql多表連接配接查詢的執行細節（一）