神奇的 SQL 之 聯表細節 → MySQL JOIN 的執行過程

問題背景

對於 MySQL 的 JOIN，不知道你們有沒有去想過他的執行流程，亦或有沒有懷疑過本身的理解（自信滿滿的自我認爲！）；若是你們不知道怎麼檢驗，能夠試着回答以下的問題

驅動表的選擇

MySQL 會如何選擇驅動表，按從左至右的順序選擇第一個？

多表鏈接的順序

假設咱們有 3 張表：A、B、C，和以下 SQL

-- 僞 SQL，不能直接執行
A LEFT JOIN B ON B.aId = A.id
LEFT JOIN C ON C.aId = A.id
WHERE A.name = '666' AND B.state = 1 AND C.create_time > '2019-11-22 12:12:30'

是 A 和 B 聯表處理完以後的結果再和 C 進行聯表處理，仍是 A、B、C 一塊兒聯表以後再進行過濾處理 ，仍是說這兩種都不對，有其餘的處理方式 ？

ON、WHERE 的生效時機

樓主無心之間逛到了一篇博文，它裏面有以下介紹

摘自 Mysql - JOIN詳解

看完這個，樓主第一時間有發現新大陸的感受，原來 JOIN 的執行順序是這樣的，可後面越想越不對，感受像是學錯了技能

若是兩表各有幾百上千萬的數據，那這兩張表作笛卡爾積，結果不敢想象！也就是說 正經圖1 中的順序還有待商榷，ON 和 WHERE 的生效時間也有待商榷

若是你對上述問題都瞭如指掌，那請你走開，別妨礙我裝逼；若是你對上述問題還不是特別清楚，那麼請坐好，我要開始裝逼了

驅動表

何謂驅動表，指多表關聯查詢時，第一個被處理的表，亦可稱之爲基表，而後再使用此表的記錄去關聯其餘表。驅動表的選擇遵循一個原則：在對最終結果集沒影響的前提下，優先選擇結果集最少的那張表做爲驅動表。這個原則說的很差懂，結果集最少，這個也許咱們能估出來，但對最終結果集不影響，這個就很差判斷了，難歸難，但仍是有必定規律的：

LEFT JOIN 通常以左表爲驅動表（RIGHT JOIN通常則是右表 ），INNER JOIN 通常以結果集少的表爲驅動表，若是還以爲有疑問，則可用 EXPLAIN 來找驅動表，其結果的第一張表便是驅動表。
你覺得 EXPLAIN 就必定準嗎 ？ 執行計劃在真正執行的時候是可能改變的！

絕大多少狀況下是適用的，特別是 EXPLAIN

LEFT JOIN 某些狀況下會被查詢優化器優化成 INNER JOIN；結果集指的是表中記錄過濾後的結果，而不是表中的全部記錄，若是無過濾條件則是表中全部記錄

更多信息可查看：Mysql多表鏈接查詢的執行細節（一）

SQL 執行的流程圖

當咱們向 MySQL 發送一個請求的時候，MySQL 到底作了些了什麼

 

SQL 執行路徑，摘自《高性能MySQL》

能夠看到，執行計劃是查詢優化器的輸出結果，執行引擎根據執行計劃來查詢數據

數據準備

MySQL 5.7.1，InnoDB 引擎；建表 SQL 和 數據初始 SQL

-- 表建立與數據初始化
DROP TABLE IF EXISTS tbl_user;
CREATE TABLE tbl_user (
  id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主鍵',
  user_name VARCHAR(50) NOT NULL COMMENT '用戶名',
  sex TINYINT(1) NOT NULL COMMENT '性別, 1:男，0:女',
  create_time datetime NOT NULL COMMENT '建立時間',
  update_time datetime NOT NULL COMMENT '更新時間',
    remark VARCHAR(255) NOT NULL DEFAULT '' COMMENT '備註',
  PRIMARY KEY (id)
) COMMENT='用戶表';

DROP TABLE IF EXISTS tbl_user_login_log;
CREATE TABLE tbl_user_login_log (
  id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主鍵',
  user_name VARCHAR(50) NOT NULL COMMENT '用戶名',
  ip VARCHAR(15) NOT NULL COMMENT '登陸IP',
  client TINYINT(1) NOT NULL COMMENT '登陸端, 1:android, 2:ios, 3:PC, 4:H5',
  create_time datetime NOT NULL COMMENT '建立時間',
  PRIMARY KEY (id)
) COMMENT='登陸日誌';
INSERT INTO tbl_user(user_name,sex,create_time,update_time,remark) VALUES
('何天香',1,NOW(), NOW(),'朗眉星目，一表人材'),
('薛沉香',0,NOW(), NOW(),'天星樓的總樓主薛搖紅的女兒，也是天星樓的少總樓主，體態豐盈，烏髮飄逸，指若春蔥，袖臂如玉，風姿卓然，高貴典雅，人稱「天星絕香」的武林第一大美女'),
('慕容蘭娟',0,NOW(), NOW(),'武林東南西北四大世家之北世家慕容長明的獨生女兒，生得玲瓏剔透，粉雕玉琢，脾氣倒是剛烈無比，又喜着火紅，因此人送綽號「火鳳凰」，是除天星樓薛沉香以外的武林第二大美女'),
('萇婷',0,NOW(), NOW(),'當今皇上最寵愛的侄女，北王府的郡主，腰肢纖細，遍體羅綺，眉若墨畫，脣點櫻紅；雖無沉香之雅重，蘭娟之熱烈，卻別現出一種空靈'),
('柳含姻',0,NOW(), NOW(),'武林四絕之一的添愁仙子董婉婉的徒弟，體態窈窕，姿容秀麗，真個是秋水爲神玉爲骨，芙蓉如面柳如腰，眉若墨畫，脣若點櫻，不弱西子半分，更勝玉環一籌; 搖紅樓、聽雨軒，琵琶一曲值千金!'),
('李凝雪',0,NOW(), NOW(),'李相國的女兒，神采奕奕，英姿颯爽，愛憎分明'),
('周遺夢',0,NOW(), NOW(),'音神傳人，湘妃竹琴的擁有者，雲髻高盤，穿了一身黑色蟬翼紗衫，愈以爲冰肌玉骨，粉面櫻脣，格外嬌豔動人'),
('葉留痕',0,NOW(), NOW(),'聖域聖女，膚白如雪，白衣飄飄，宛如仙女通常，微笑中帶着說不出的柔和之美'),
('郭疏影',0,NOW(), NOW(),'揚灰右使的徒弟，秀髮細眉，玉肌豐滑，嬌潤脫俗'),
('鍾鈞天',0,NOW(), NOW(),'天界，玄天九部 - 鈞天部的部主，超凡脫俗，仙氣逼人'),
('王雁雲',0,NOW(), NOW(),'塵緣山莊二小姐，刁蠻任性'),
('許侍霜',0,NOW(), NOW(),'藥王谷谷主女兒，醫術高明'),
('馮黯凝',0,NOW(), NOW(),'桃花門門主，嬌豔如火，千嬌百媚');
INSERT INTO tbl_user_login_log(user_name, ip, client, create_time) VALUES
('薛沉香', '10.53.56.78',2, '2019-10-12 12:23:45'),
('萇婷', '10.53.56.78',2, '2019-10-12 22:23:45'),
('慕容蘭娟', '10.53.56.12',1, '2018-08-12 22:23:45'),
('何天香', '10.53.56.12',1, '2019-10-19 10:23:45'),
('柳含姻', '198.11.132.198',2, '2018-05-12 22:23:45'),
('馮黯凝', '198.11.132.198',2, '2018-11-11 22:23:45'),
('周遺夢', '198.11.132.198',2, '2019-06-18 22:23:45'),
('郭疏影', '220.181.38.148',3, '2019-10-21 09:45:56'),
('薛沉香', '220.181.38.148',3, '2019-10-26 22:23:45'),
('萇婷', '104.69.160.60',4, '2019-10-12 10:23:45'),
('王雁雲', '104.69.160.61',4, '2019-10-16 20:23:45'),
('李凝雪', '104.69.160.62',4, '2019-10-17 20:23:45'),
('許侍霜', '104.69.160.63',4, '2019-10-18 20:23:45'),
('葉留痕', '104.69.160.64',4, '2019-10-19 20:23:45'),
('王雁雲', '104.69.160.65',4, '2019-10-20 20:23:45'),
('葉留痕', '104.69.160.66',4, '2019-10-21 20:23:45');

SELECT * FROM tbl_user;
SELECT * FROM tbl_user_login_log;

單表查詢

單表查詢的過程比較好理解，大體以下

 

關於單表查詢就不細講了，主要涉及到：彙集索引，覆蓋索引、回表操做，知道這 3 點，上圖就好理解了（不知道的趕快去查資料，暴露了就丟人了！）。

聯表算法

MySQL 的聯表算法是基於嵌套循環算法（nested-loop algorithm）而衍生出來的一系列算法，根據不一樣條件而選用不一樣的算法

在使用索引關聯的狀況下，有 Index Nested-Loop join 和 Batched Key Access join 兩種算法;
在未使用索引關聯的狀況下，有 Simple Nested-Loop join 和 Block Nested-Loop join 兩種算法;　　

Simple Nested-Loop

簡單嵌套循環，簡稱 SNL；逐條逐條匹配，就像這樣

 

 

這種算法簡單粗暴，但毫無性能可言，時間性能上來講是 n（表中記錄數） 的 m（表的數量） 次方，因此 MySQL 作了優化，聯表查詢的時候不會出現這種算法，即便在無 WHERE 條件且 ON 的鏈接鍵上無索引時，也不會選用這種算法

Block Nested-Loop

緩存塊嵌套循環鏈接，簡稱 BNL，是對 INL 的一種優化；一次性緩存多條驅動表的數據，而後拿 Join Buffer 裏的數據批量與內層循環讀取的數據進行匹配，就像這樣

 

將內部循環中讀取的每一行與緩衝區中的全部記錄進行比較，這樣就能夠減小內層循環的讀表次數。舉個例子，若是沒有 Join Buffer，驅動表有 30 條記錄，被驅動表有 50 條記錄，那麼內層循環的讀表次數應該是 30 * 50 = 1500，若是 Join Buffer 可用並能夠存 10 條記錄（Join Buffer 存儲的是驅動表中參與查詢的列，包括 SELECT 的列、ON 的列、WHERE 的列，而不是驅動表中整行整行的完整記錄），那麼內層循環的讀表次數應該是 30 / 10 * 50 = 150，被驅動表必須讀取的次數減小了一個數量級。

當被驅動表在鏈接鍵上無索引且被驅動表在 WHERE 過濾條件上也沒索引時，經常會採用此種算法來完成聯表，以下所示

 

 

Index Nested-Loop

索引嵌套循環，簡稱 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 好強大？

總結

一、驅動表的選擇有它的一套算法，有興趣的能夠去專研下；比較靠譜的肯定方法是用 EXPLAIN

二、聯表順序，不是兩兩聯合以後，再去聯合第三張表，而是驅動表的一條記錄穿到底，匹配完全部關聯表以後，再取驅動表的下一條記錄重複聯表操做；

三、MySQL 的鏈接算法基於嵌套循環算法，基於不一樣的狀況而採用不一樣的衍生算法

四、關於 ON 和 WHERE，咱們下篇詳細講解，你們能夠先考慮下它們的區別，以及生效時間