mysql join語句原理
JOIN語句原理
join方式連線多個表，本質就是各個表之間資料的迴圈匹配。MySQL5.5版本之前，MySQL只支援一種表間關聯方式，就是巢狀迴圈(Nested Loop Join)。如果關聯表的資料量很大，
則join關聯的執行時間會非常長。在MySQL5.5以後的版本中，MySQL通過引入BNLJ演算法來優化巢狀執行。
驅動表和被驅動表
驅動表就是主表，被驅動表就是從表、非驅動表
SELECT * FROM A JOIN B ON ...
A一定是驅動表嗎？不一定，優化器會根據你查詢語句做優化，決定先查哪張表。先查詢的那張表就是驅動表，反之就是被驅動表。通過explain關鍵字可以檢視。
- 左外連線加where作為篩選條件，查詢優化器幫我做了優化，把b作為驅動表，a作為被驅動表
- 左外連線加and，將and都作為on的條件，這也是和上面的where的區別。（這裡查詢優化器沒有幫我們進行調整）
- 採用內連線
三種迴圈匹配
Simple Nested-Loop Join(簡單巢狀迴圈匹配)
演算法相當簡單，從表A中取出一條資料1，遍歷表B，將匹配到的資料放到result…以此類推，驅動表A中的每一條記錄與被驅動表B的記錄進行判斷：
可以看到這種方式效率是非常低的，以上述表A資料100條，表B資料1000條計算，則A*B= 10萬次。開銷統計如下：
Index Nested-Loop Join（巢狀迴圈連線）
Index Nested-Loop Join其優化思路主要是為了減少內層表資料的匹配次數，所以要求被驅動表上必須有索引才行。通過外層表匹配條件直接與內層表索引進行匹配，避免和內層表每層記錄進行比較，這樣極大的減少了對內層表的匹配次數。
驅動表中的每條記錄通過被驅動表的索引進行訪問，因為索引查詢的成本是比較固定的，故mysql優化器都傾向於使用記錄數少的表作為驅動表(外表)。
如果被驅動表加索引，效率是非常高的，但如果索引不是主鍵索引，所以還得進行一次回表查詢。相比，被驅動表的索引是主鍵索引，效率會更高。
Block Nest-Loop Join（塊巢狀迴圈連線）
如果存在索引，那麼會使用index的方式進行join，如果join的列沒有索引，被驅動表要掃描的次數太多了。每次訪問被驅動表，其表中的記錄都會被載入到記憶體中，然後再從驅動表中取一條與其匹配，匹配結束後清除記憶體，然後再從驅動表中載入一條記錄，然後把被驅動表的記錄在載入到記憶體匹配，這樣周而復始，大大增加了IO的次數。為了減少被驅動表的IO次數，就出現了Block Nested-Loop Join的方式。
不再是逐條獲取驅動表的資料，而是一塊一塊的獲取，引入了join buffer緩衝區，將驅動表join相關的部分資料列(大小受join buffer的限制)快取到join buffer中，然後全表掃描被驅動表，被驅動表的每一條記錄一次性和join buffer中的所有驅動表記錄進行匹配(記憶體中操作)，將簡單巢狀迴圈中的多次比較合併成一次，降低了被驅動表的訪問頻率。
注意：
- 這裡快取的不只是關聯表的列，select後面的列也會快取起來。(所有儘量少投影*)
- 在一個有N個join關聯的sql中會分配N-1個join buffer。所以查詢的時候儘量減少不必要的欄位，可以讓join buffer中可以存放更多的列。
引數設定：
- block_nested_loop
通過show variables like '%optimizer_switch' 檢視block_nested_loop狀態。預設是開啟的。
show variables like '%optimizer_switch';
- join_buffer
驅動表不能一次性載入完，要看join buffer能不能儲存所有的資料，預設情況下join_buffer_size=256k
show variables like '%join_buffer%';
mysql> show variables like '%join_buffer%';
+------------------+--------+
| Variable_name | Value |
+------------------+--------+
| join_buffer_size | 262144 |
+------------------+--------+
1 row in set (0.00 sec)
join_buffer_size的最大值在32位系統可以申請4G，而在64位操做系統下可以申請大於4G的Join Buffer空間(64位Windows除外，其大值會被截斷為4GB併發出警告)。
Join小結
- 整體效果比較：INLJ > BNLJ > SNLJ
- 永遠用小結果集驅動大結果集(其本質就是減少外層迴圈的資料數量) (小的度量單位指的是錶行數*每行大小)(也就是要看過濾以後的結果集)
案例：假設t2表的欄位數量大於1，如果用第二的話，t2.*要比t1.b的欄位要多，在join_buffer裡面能載入到的條目數就減少了。
select t1.b, t2.* from t1 straight.join t2 on (t1.b=t2.b) where t2.id<=108;#推薦
select t1.b,t2.* from t2 straight_join t1 on (t1.b=t2.b) where t2.id<=100;#不推薦
- 為被驅動表匹配的條件新增索引(減少內層迴圈匹配次數)
- 增加join buffer size的大小(一次快取的資料越多，那麼內層包的掃描次數就越少)
- 減少驅動表不必要的欄位查詢（欄位越少，join buffer所快取的資料就越多）
Hash Join
從MySQL的8.0.20版本開始將廢棄BNLJ，因為從MySQL8.0.18版本開始就加入了hash join預設都會使用hash join
- Nested Loop 對於被連線的資料子集較小的情況，Nested Loop是個較好的選擇。
- Hash Join是做大資料集連線時的常用方式，優化器使用兩個表中較小(相對較小)的表利用Join Key在記憶體中建立散列表，然後掃描較大的表並探測散列表，找出與Hash表匹配的行。
- 這種方式適用於較小的表完全可以放於記憶體中的情況，這樣總成本就是訪問兩個表的成本之和。
- 在表很大的情況下並不能完全放入記憶體，這時優化器會將它分割成若干不同的分割槽，不能放入記憶體的部分就把該分割槽寫入磁碟的臨時段，此時要求有較大的臨時段從而儘量提高I/O的效能。
- 它能夠很好的工作於沒有索引的大表和並行查詢的環境中，並提供最好的效能。大多數人都說它是Join的重型升降機。Hash Join只能應用於等值連線(如WHERE A.COL1=B.COL2)，這是由Hash的特點決定的。
總結
- 保證被驅動表的JOIN欄位已經建立了索引
- 需要JOIN的欄位，資料型別保持絕對一致。
- LEFT JOIN時，選擇小表作為驅動表，大表作為被驅動表。減少外層迴圈的次數。
- INNER JOIN時，MySQL會自動將小結果集的表選為驅動表。選擇相信MySQL優化策略。
- 能夠直接多表關聯的儘量直接關聯，不用子查詢。(減少查詢的趟數)
- 不建議使用子查詢，建議將子查詢SQL拆開結合程式多次查詢，或使用JOIN來代替子查詢。
- 衍生表建不了索引