34講到底可不可以使用join

在實際生產中，關於join語句使用的問題，一般會集中在以下兩類：

我們DBA不讓使用join，使用join有什麼問題呢？
如果有兩個大小不同的表做join，應該用哪個表做驅動表呢？

今天這篇文章，我就先跟你說說join語句到底是怎麼執行的，然後再來回答這兩個問題。

爲了便於量化分析，我還是創建兩個表t1和t2來和你說明。

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)

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

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是被驅動表。

現在，我們來看一下這條語句的explain結果。

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

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

這個過程是先遍歷表t1，然後根據從表t1中取出的每行數據中的a值，去表t2中查找滿足條件的記錄。在形式上，這個過程就跟我們寫程序時的嵌套查詢類似，並且可以用上被驅動表的索引，所以我們稱之爲“Index Nested-Loop Join”，簡稱NLJ。

它對應的流程圖如下所示：

在這個流程裏：

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

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

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

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

執行select * from t1，查出表t1的所有數據，這裏有100行；
循環遍歷這100行數據：

從每一行R取出字段a的值$R.a；
執行select * from t2 where a=$R.a；
把返回的結果和R構成結果集的一行。

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

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

我們再來看看第二個問題：怎麼選擇驅動表？

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

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

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

因此整個執行過程，近似複雜度是 N + N2log2M。

顯然，N對掃描行數的影響更大，因此應該讓小表來做驅動表。

如果你沒覺得這個影響有那麼“顯然”，可以這麼理解：N擴大1000倍的話，掃描行數就會擴大1000倍；而M擴大1000倍，掃描行數擴大不到10倍。

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

使用join語句，性能比強行拆成多個單表執行SQL語句的性能要好；
如果使用join語句的話，需要讓小表做驅動表。

但是，你需要注意，這個結論的前提是“可以使用被驅動表的索引”。

接下來，我們再看看被驅動表用不上索引的情況。

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。

Block Nested-Loop Join

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

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

這個過程的流程圖如下：

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

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

前面我們說過，如果使用Simple Nested-Loop Join算法進行查詢，掃描行數也是10萬行。因此，從時間複雜度上來說，這兩個算法是一樣的。但是，Block Nested-Loop Join算法的這10萬次判斷是內存操作，速度上會快很多，性能也更好。

接下來，我們來看一下，在這種情況下，應該選擇哪個表做驅動表。

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

兩個表都做一次全表掃描，所以總的掃描行數是M+N；
內存中的判斷次數是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);

執行過程就變成了：

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

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

圖中的步驟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)。

所以，在這個算法的執行過程中：

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

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

所以結論是，應該讓小表當驅動表。

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

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

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

理解了MySQL執行join的兩種算法，現在我們再來試着回答文章開頭的兩個問題。

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

如果可以使用Index Nested-Loop Join算法，也就是說可以用上被驅動表上的索引，其實是沒問題的；
如果使用Block Nested-Loop Join算法，掃描行數就會過多。尤其是在大表上的join操作，這樣可能要掃描被驅動表很多次，會佔用大量的系統資源。所以這種join儘量不要用。

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

第二個問題是：如果要使用join，應該選擇大表做驅動表還是選擇小表做驅動表？

如果是Index Nested-Loop Join算法，應該選擇小表做驅動表；
如果是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的各個字段的總數據量，數據量小的那個表，就是“小表”，應該作爲驅動表。

小結

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

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

如果可以使用被驅動表的索引，join語句還是有其優勢的；
不能使用被驅動表的索引，只能使用Block Nested-Loop Join算法，這樣的語句就儘量不要使用；
在使用join的時候，應該讓小表做驅動表。

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

我們在上文說到，使用Block Nested-Loop Join算法，可能會因爲join_buffer不夠大，需要對被驅動表做多次全表掃描。

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

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

上期問題時間

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

這個問題的核心是，造成了“長事務”。

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

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

評論區留言點贊板：

@老楊同志提到了更新之間會互相等鎖的問題。同一個事務，更新之後要儘快提交，不要做沒必要的查詢，尤其是不要執行需要返回大量數據的查詢；
@長傑同學提到了undo表空間變大，db服務堵塞，服務端磁盤空間不足的例子。

34講到底可不可以使用join

Index Nested-Loop Join

Simple Nested-Loop Join

Block Nested-Loop Join

小結

上期問題時間

什麼是ObjectFactory？什麼是ObjectProvider？

19講爲什麼我只查一行的語句，也執行這麼慢

38講都說InnoDB好，那還要不要使用Memory引擎

31講誤刪數據後除了跑路，還能怎麼辦

34講到底可不可以使用join

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結