MySQL實戰45講學習筆記：第三十四講

1、本節概述

在實際生產中，關於 join 語句使用的問題，通常會集中在如下兩類：

1. 咱們 DBA 不讓使用 join，使用 join 有什麼問題呢？
2. 若是有兩個大小不一樣的表作 join，應該用哪一個表作驅動表呢？

今天這篇文章，我就先跟你說說 join 語句究竟是怎麼執行的，而後再來回答這兩個問題。爲了便於量化分析，我仍是建立兩個表 t1 和 t2 來和你說明。

能夠看到，這兩個表都有一個主鍵索引 id 和一個索引 a，字段 b 上無索引。存儲過程idata() 往表 t2 裏插入了 1000 行數據，在表 t1 裏插入的是 100 行數據。

CREATE TABLE `t2` (
  `id` int(11) NOT NULL,
  `a` int(11) DEFAULT NULL,
  `b` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `a` (`a`)
) ENGINE=InnoDB;

drop procedure idata;
delimiter ;;
create procedure idata()
begin
  declare i int;
  set i=1;
  while(i<=1000)do
    insert into t2 values(i, i, i);
    set i=i+1;
  end while;
end;;
delimiter ;
call idata();

create table t1 like t2;
insert into t1 (select * from t2 where id<=100)

2、Index Nested-Loop Join

咱們來看一下這個語句：

select * from t1 straight_join t2 on (t1.a=t2.a);

若是直接使用 join 語句，MySQL 優化器可能會選擇表 t1 或 t2 做爲驅動表，這樣會影響咱們分析 SQL 語句的執行過程。

因此，爲了便於分析執行過程當中的性能問題，我改用straight_join 讓 MySQL 使用固定的鏈接方式執行查詢，這樣優化器只會按照咱們指定的方式去 join。在這個語句裏，t1 是驅動表，t2 是被驅動表

一、使用索引字段 join 的 explain 結果

如今，咱們來看一下這條語句的 explain 結果

圖 1 使用索引字段 join 的 explain 結果

能夠看到，在這條語句裏，被驅動表 t2 的字段 a 上有索引，join 過程用上了這個索引，所以這個語句的執行流程是這樣的：

1. 從表 t1 中讀入一行數據 R；
2. 從數據行 R 中，取出 a 字段到表 t2 裏去查找；
3. 取出表 t2 中知足條件的行，跟 R 組成一行，做爲結果集的一部分；
4. 重複執行步驟 1 到 3，直到表 t1 的末尾循環結束。

這個過程是先遍歷表 t1，而後根據從表 t1 中取出的每行數據中的 a 值，去表 t2 中查找知足條件的記錄。在形式上，這個過程就跟咱們寫程序時的嵌套查詢相似，

而且能夠用上被驅動表的索引，因此咱們稱之爲「Index Nested-Loop Join」，簡稱 NLJ。

二、 Index Nested-Loop Join 算法的執行流程

圖 2 Index Nested-Loop Join 算法的執行流程

在這個流程裏：

1. 對驅動表 t1 作了全表掃描，這個過程須要掃描 100 行；
2. 而對於每一行 R，根據 a 字段去表 t2 查找，走的是樹搜索過程。因爲咱們構造的數據都是一一對應的，所以每次的搜索過程都只掃描一行，也是總共掃描 100 行；
3. 因此，整個執行流程，總掃描行數是 200。

如今咱們知道了這個過程，再試着回答一下文章開頭的兩個問題。

三、先看第一個問題：能不能使用 join?

假設不使用 join，那咱們就只能用單表查詢。咱們看看上面這條語句的需求，用單表查詢怎麼實現。

1. 執行select * from t1，查出表 t1 的全部數據，這裏有 100 行；
2. 循環遍歷這 100 行數據：

能夠看到，在這個查詢過程，也是掃描了 200 行，可是總共執行了 101 條語句，比直接join 多了 100 次交互。除此以外，客戶端還要本身拼接 SQL 語句和結果。

顯然，這麼作還不如直接 join 好。

四、怎麼選擇驅動表？

在這個 join 語句執行過程當中，驅動表是走全表掃描，而被驅動表是走樹搜索。

假設被驅動表的行數是 M。每次在被驅動表查一行數據，要先搜索索引 a，再搜索主鍵索引。每次搜索一棵樹近似複雜度是以 2 爲底的 M 的對數，記爲 log M，因此在被驅動表上查一行的時間複雜度是 2*log M。

假設驅動表的行數是 N，執行過程就要掃描驅動表 N 行，而後對於每一行，到被驅動表上匹配一次。

所以整個執行過程，近似複雜度是 N + N*2*log M。

顯然，N 對掃描行數的影響更大，所以應該讓小表來作驅動表。

若是你沒以爲這個影響有那麼「顯然」， 能夠這麼理解：N 擴大 1000 倍的話，掃描行數就會擴大 1000 倍；而 M 擴大 1000 倍，掃描行數擴大不到10 倍。

到這裏小結一下，經過上面的分析咱們獲得了兩個結論：

1. 使用 join 語句，性能比強行拆成多個單表執行 SQL 語句的性能要好；
2. 若是使用 join 語句的話，須要讓小表作驅動表。

可是，你須要注意，這個結論的前提是「可使用被驅動表的索引」。接下來，咱們再看看被驅動表用不上索引的狀況。

3、Simple Nested-Loop Join

如今，咱們把 SQL 語句改爲這樣：

select * from t1 straight_join t2 on (t1.a=t2.b);

因爲表 t2 的字段 b 上沒有索引，所以再用圖 2 的執行流程時，每次到 t2 去匹配的時候，就要作一次全表掃描。

你能夠先設想一下這個問題，繼續使用圖 2 的算法，是否是能夠獲得正確的結果呢？若是隻看結果的話，這個算法是正確的，並且這個算法也有一個名字，叫作「Simple Nested-Loop Join」。

可是，這樣算來，這個 SQL 請求就要掃描表 t2 多達 100 次，總共掃描 100*1000=10 萬行

這還只是兩個小表，若是 t1 和 t2 都是 10 萬行的表（固然了，這也仍是屬於小表的範圍），就要掃描 100 億行，這個算法看上去太「笨重」了。

固然，MySQL 也沒有使用這個 Simple Nested-Loop Join 算法，而是使用了另外一個叫做「Block Nested-Loop Join」的算法，簡稱 BNL。

4、Block Nested-Loop Join

一、Block Nested-Loop Join 算法的執行流程

這時候，被驅動表上沒有可用的索引，算法的流程是這樣的：

1. 把表 t1 的數據讀入線程內存 join_buffer 中，因爲咱們這個語句中寫的是 select *，所以是把整個表 t1 放入了內存；
2. 掃描表 t2，把表 t2 中的每一行取出來，跟 join_buffer 中的數據作對比，知足 join 條件的，做爲結果集的一部分返回。

這個過程的流程圖以下：

圖 3 Block Nested-Loop Join 算法的執行流程

二、不使用索引字段 join 的 explain 結果

對應地，這條 SQL 語句的 explain 結果以下所示：

圖 4 不使用索引字段 join 的 explain 結果

能夠看到，在這個過程當中，對錶 t1 和 t2 都作了一次全表掃描，所以總的掃描行數是1100。因爲 join_buffer 是以無序數組的方式組織的，所以對錶 t2 中的每一行，
都要作100 次判斷，總共須要在內存中作的判斷次數是：100*1000=10 萬次。

前面咱們說過，若是使用 Simple Nested-Loop Join 算法進行查詢，掃描行數也是 10 萬行。所以，從時間複雜度上來講，這兩個算法是同樣的。可是，Block Nested-Loop Join

算法的這 10 萬次判斷是內存操做，速度上會快不少，性能也更好。

接下來，咱們來看一下，在這種狀況下，應該選擇哪一個表作驅動表。

假設小表的行數是 N，大表的行數是 M，那麼在這個算法裏：

1. 兩個表都作一次全表掃描，因此總的掃描行數是 M+N；
2. 內存中的判斷次數是 M*N。

能夠看到，調換這兩個算式中的 M 和 N 沒差異，所以這時候選擇大表仍是小表作驅動表，執行耗時是同樣的。

而後，你可能立刻就會問了，這個例子裏表 t1 才 100 行，要是表 t1 是一個大表，join_buffer 放不下怎麼辦呢？

join_buffer 的大小是由參數 join_buffer_size 設定的，默認值是 256k。若是放不下表 t1的全部數據話，策略很簡單，就是分段放。我把 join_buffer_size 改爲 1200，再執行：

select * from t1 straight_join t2 on (t1.a=t2.b);

三、Block Nested-Loop Join -- 兩段

執行過程就變成了：

1. 掃描表 t1，順序讀取數據行放入 join_buffer 中，放完第 88 行 join_buffer 滿了，繼續第 2 步；
2. 掃描表 t2，把 t2 中的每一行取出來，跟 join_buffer 中的數據作對比，知足 join 條件的，做爲結果集的一部分返回；
3. 清空 join_buffer；
4. 繼續掃描表 t1，順序讀取最後的 12 行數據放入 join_buffer 中，繼續執行第 2 步。

執行流程圖也就變成這樣：

圖 5 Block Nested-Loop Join -- 兩段

圖中的步驟 4 和 5，表示清空 join_buffer 再複用。這個流程才體現出了這個算法名字中「Block」的由來，表示「分塊去 join」。

能夠看到，這時候因爲表 t1 被分紅了兩次放入 join_buffer 中，致使表 t2 會被掃描兩次。雖然分紅兩次放入 join_buffer，可是判斷等值條件的次數仍是不變的，依然是(88+12)*1000=10 萬次。

咱們再來看下，在這種狀況下驅動表的選擇問題。

假設，驅動表的數據行數是 N，須要分 K 段才能完成算法流程，被驅動表的數據行數是M。

注意，這裏的 K 不是常數，N 越大 K 就會越大，所以把 K 表示爲λ*N，顯然λ的取值範圍是 (0,1)。

因此，在這個算法的執行過程當中：

1. 掃描行數是 N+λ*N*M；
2. 內存判斷 N*M 次。

顯然，內存判斷次數是不受選擇哪一個表做爲驅動表影響的。而考慮到掃描行數，在 M 和N 大小肯定的狀況下，N 小一些，整個算式的結果會更小。

因此結論是，應該讓小表當驅動表。

固然，你會發現，在 N+λ*N*M 這個式子裏，λ纔是影響掃描行數的關鍵因素，這個值越小越好。

剛剛咱們說了 N 越大，分段數 K 越大。那麼，N 固定的時候，什麼參數會影響 K 的大小呢？（也就是λ的大小）答案是 join_buffer_size。join_buffer_size 越大，一次能夠放入
的行越多，分紅的段數也就越少，對被驅動表的全表掃描次數就越少。

這就是爲何，你可能會看到一些建議告訴你，若是你的 join 語句很慢，就把join_buffer_size 改大。

四、回答文章開頭的兩個問題。

一、第一個問題：能不能使用 join 語句？

1. 若是可使用 Index Nested-Loop Join 算法，也就是說能夠用上被驅動表上的索引，實際上是沒問題的；
2. 若是使用 Block Nested-Loop Join 算法，掃描行數就會過多。尤爲是在大表上的 join操做，這樣可能要掃描被驅動表不少次，會佔用大量的系統資源。因此這種 join 儘可能不要用。

因此你在判斷要不要使用 join 語句時，就是看 explain 結果裏面，Extra 字段裏面有沒有出現「Block Nested Loop」字樣。

二、第二個問題是：若是要使用 join，應該選擇大表作驅動表仍是選擇小表作驅動表？

1. 若是是 Index Nested-Loop Join 算法，應該選擇小表作驅動表；
2. 若是是 Block Nested-Loop Join 算法：

在 join_buffer_size 足夠大的時候，是同樣的；

在 join_buffer_size 不夠大的時候（這種狀況更常見），應該選擇小表作驅動表。

因此，這個問題的結論就是，老是應該使用小表作驅動表

三、什麼叫做「小表」。

固然了，這裏我須要說明下，什麼叫做「小表」。

咱們前面的例子是沒有加條件的。若是我在語句的 where 條件加上 t2.id<=50 這個限定條件，再來看下這兩條語句：

select * from t1 straight_join t2 on (t1.b=t2.b) where t2.id<=50;
select * from t2 straight_join t1 on (t1.b=t2.b) where t2.id<=50;

注意，爲了讓兩條語句的被驅動表都用不上索引，因此 join 字段都使用了沒有索引的字段b。

但若是是用第二個語句的話，join_buffer 只須要放入 t2 的前 50 行，顯然是更好的。因此這裏，「t2 的前 50 行」是那個相對小的表，也就是「小表」。

咱們再來看另一組例子：

select t1.b,t2.* from  t1  straight_join t2 on (t1.b=t2.b) where t2.id<=100;
select t1.b,t2.* from  t2  straight_join t1 on (t1.b=t2.b) where t2.id<=100;

這個例子裏，表 t1 和 t2 都是隻有 100 行參加 join。可是，這兩條語句每次查詢放入join_buffer 中的數據是不同的：

表 t1 只查字段 b，所以若是把 t1 放到 join_buffer 中，則 join_buffer 中只須要放入 b的值；

表 t2 須要查全部的字段，所以若是把表 t2 放到 join_buffer 中的話，就須要放入三個字段 id、a 和 b。

這裏，咱們應該選擇表 t1 做爲驅動表。也就是說在這個例子裏，「只須要一列參與 join的表 t1」是那個相對小的表。

因此，更準確地說，在決定哪一個表作驅動表的時候，應該是兩個表按照各自的條件過濾，過濾完成以後，計算參與 join 的各個字段的總數據量，數據量小的那個表，就是「小
表」，應該做爲驅動表。

5、小結

今天，我和你介紹了 MySQL 執行 join 語句的兩種可能算法，這兩種算法是由可否使用被驅動表的索引決定的。而可否用上被驅動表的索引，對 join 語句的性能影響很大。

經過對 Index Nested-Loop Join 和 Block Nested-Loop Join 兩個算法執行過程的分析，咱們也獲得了文章開頭兩個問題的答案：

1. 若是可使用被驅動表的索引，join 語句仍是有其優點的；
2. 不能使用被驅動表的索引，只能使用 Block Nested-Loop Join 算法，這樣的語句就儘可能不要使用；
3. 在使用 join 的時候，應該讓小表作驅動表。

最後，又到了今天的問題時間。

咱們在上文說到，使用 Block Nested-Loop Join 算法，可能會由於 join_buffer 不夠大，須要對被驅動表作屢次全表掃描。

個人問題是，若是被驅動表是一個大表，而且是一個冷數據表，除了查詢過程當中可能會致使 IO 壓力大之外，你以爲對這個 MySQL 服務還有什麼更嚴重的影響嗎？（這個問題需
要結合上一篇文章的知識點）

你能夠把你的結論和分析寫在留言區，我會在下一篇文章的末尾和你討論這個問題。感謝你的收聽，也歡迎你把這篇文章分享給更多的朋友一塊兒閱讀。

6、上期問題時間

我在上一篇文章最後留下的問題是，若是客戶端因爲壓力過大，遲遲不能接收數據，會對服務端形成什麼嚴重的影響。

這個問題的核心是，形成了「長事務」。

至於長事務的影響，就要結合咱們前面文章中提到的鎖、MVCC 的知識點了。

若是前面的語句有更新，意味着它們在佔用着行鎖，會致使別的語句更新被鎖住；固然讀的事務也有問題，就是會致使 undo log 不能被回收，致使回滾段空間膨脹。

評論區留言點贊板：

@老楊同志 提到了更新之間會互相等鎖的問題。同一個事務，更新以後要儘快提交，不要作不必的查詢，尤爲是不要執行須要返回大量數據的查詢；

@長傑 同窗提到了 undo 表空間變大，db 服務堵塞，服務端磁盤空間不足的例子。