概述&背景

MySQL一直被人詬病沒有實現HashJoin，最新發布的8.0.18已經帶上了這個功能，令人欣喜。有時候在想，MySQL為什麼一直不支援HashJoin呢？我想可能是因為MySQL多用於簡單的OLTP場景，並且在網際網路應用居多，需求沒那麼緊急。另一方面可能是因為以前完全靠社群，這種演進速度畢竟有限，Oracle收購MySQL後，MySQL的發版演進速度明顯加快了很多。

HashJoin本身演算法實現並不複雜，要說複雜，可能是優化器配套選擇執行計劃時，是否選擇HashJoin，選擇外表，內表可能更復雜一點。不管怎樣現在已經有了HashJoin，優化器在選擇Join演算法時又多了一個選擇。MySQL本著實用主義，相信這個功能增強也迴應了一些質疑，有些功能不是沒有能力做好，而是有它的優先順序。

在8.0.18之前，MySQL只支援NestLoopJoin演算法，最簡單的就是Simple NestLoop Join，MySQL針對這個演算法做了若干優化，實現了Block NestLoop Join，Index NestLoop Join和Batched Key Access等，有了這些優化，在一定程度上能緩解對HashJoin的迫切程度。下文會單獨拿一個章節講MySQL的這些Join優化，下面先講HashJoin。

Hash Join演算法

NestLoopJoin演算法簡單來說，就是雙重迴圈，遍歷外表(驅動表)，對於外表的每一行記錄，然後遍歷內表，然後判斷join條件是否符合，進而確定是否將記錄吐出給上一個執行節點。從演算法角度來說，這是一個M*N的複雜度。HashJoin是針對equal-join場景的優化，基本思想是，將外表資料load到記憶體，並建立hash表，這樣只需要遍歷一遍內表，就可以完成join操作，輸出匹配的記錄。如果資料能全部load到記憶體當然好，邏輯也簡單，一般稱這種join為CHJ(Classic Hash Join)，之前MariaDB就已經實現了這種HashJoin演算法。如果資料不能全部load到記憶體，就需要分批load進記憶體，然後分批join，下面具體介紹這幾種join演算法的實現。

In-Memory Join(CHJ)

HashJoin一般包括兩個過程，建立hash表的build過程和探測hash表的probe過程。

1).build phase

遍歷外表，以join條件為key，查詢需要的列作為value建立hash表。這裡涉及到一個選擇外表的依據，主要是評估參與join的兩個表(結果集)的大小來判斷，誰小就選擇誰，這樣有限的記憶體更容易放下hash表。

2).probe phase

hash表build完成後，然後逐行遍歷內表，對於內表的每個記錄，對join條件計算hash值，並在hash表中查詢，如果匹配，則輸出，否則跳過。所有內表記錄遍歷完，則整個過程就結束了。過程參照下圖，來源於MySQL官方部落格

左側是build過程，右側是probe過程，country_id是equal_join條件，countries表是外表，persons表是內表。

On-Disk Hash Join

CHJ的限制條件在於，要求記憶體能裝下整個外表。在MySQL中，Join可以使用的記憶體通過引數join_buffer_size控制。如果join需要的記憶體超出了join_buffer_size，那麼CHJ將無能為力，只能對外表分成若干段，每個分段逐一進行build過程，然後遍歷內表對每個分段再進行一次probe過程。假設外表分成了N片，那麼將掃描內表N次。這種方式當然是比較弱的。在MySQL8.0中，如果join需要記憶體超過了join_buffer_size，build階段會首先利用hash算將外表進行分割槽，併產生臨時分片寫到磁碟上；然後在probe階段，對於內表使用同樣的hash演算法進行分割槽。由於使用分片hash函式相同，那麼key相同(join條件相同)必然在同一個分片編號中。接下來，再對外表和內表中相同分片編號的資料進行CHJ的過程，所有分片的CHJ做完，整個join過程就結束了。這種演算法的代價是，對外表和內表分別進行了兩次讀IO，一次寫IO。相對於之之前需要N次掃描內表IO，現在的處理方式更好。

左上側圖是外表的分片過程，右上側圖是內表的分片過程，最下面的圖是對分片進行build+probe過程。

Grace Hash Join

主流的資料庫Oracle，SQLServer，PostgreSQL早就支援了HashJoin。Join演算法都類似，這裡介紹下Oracle使用的Grace Hash Join演算法。其實整個過程與MySQL的HashJoin類似，主要有一點區別。當出現join_buffer_size不足時，MySQL會對外表進行分片，然後再進行CHJ過程。但是，極端情況下，如果資料分佈不均勻，導致大量的資料hash後都分佈在一個分桶中，導致分片後，join_buffer_size仍然不夠，MySQL的處理方式是一次讀分片讀若干記錄構建hash表，然後probe對應的外表分片。處理完一批後，清理hash表，重複上述過程，直到這個分片的所有資料處理完為止。這個過程與CHJ在join_buffer_size不足時，處理邏輯相同。

GraceHash在遇到這種情況時，會繼續分片進行二次Hash，直到記憶體足夠放下一個hash表為止。但是，這裡仍然有極端情況，如果輸入join條件都相同，那麼無論進行多少次Hash，都沒法分開，那麼這個時候GraceHashJoin也退化成和MySQL的處理方式一樣。

hybrid hash join

與GraceHashJoin的區別在於，如果快取能快取足夠多的分片資料，會盡量快取，那麼就不必像GraceHash那樣，嚴格地將所有分片都先讀進記憶體，然後寫到外存，然後再讀進記憶體去走build過程。這個是在記憶體相對於分片比較充裕的情況下的一種優化，目的是為了減少磁碟的讀寫IO。目前Oceanbase的HashJoin採用的是這種join方式。

MySQL-Join演算法優化

在MySQL8.0.18之前，也就是在很長一段時間內，MySQL資料庫並沒有HashJoin，主要的Join演算法是NestLoopJoin。SimpleNestLoopJoin顯然是很低效的，對內表需要進行N次全表掃描，實際複雜度是N*M，N是外表的記錄數目，M是記錄數，代表一次掃描內表的代價。為此，MySQL針對SimpleNestLoopJoin做了若干優化，下面貼的圖片均來自網路。

BlockNestLoopJoin(BNLJ)

MySQL採用了批量技術，即一次利用join_buffer_size快取足夠多的記錄，每次遍歷內表時，每條內表記錄與這一批資料進行條件判斷，這樣就減少了掃描內表的次數，如果內表比較大，間接就緩解了IO的讀壓力。

IndexNestLoopJoin(INLJ)

如果我們能對內表的join條件建立索引，那麼對於外表的每條記錄，無需再進行全表掃描內表，只需要一次Btree-Lookup即可，整體時間複雜度降低為N*O(logM)。對比HashJoin，對於外表每條記錄，HashJoin是一次HashTable的search，當然HashTable也有build時間，還需要處理記憶體不足的情況，不一定比INLJ好。

Batched Key Access

IndexNestLoopJoin利用join條件的索引，通過Btree-Lookup去匹配減少了遍歷內表的代價。如果join條件是非主鍵列，那麼意味著大量的回表和隨機IO。BKA優化的做法是，將滿足條件的一批資料按主鍵排序，這樣回表時，從主鍵的角度來說就相對有序，緩解隨機IO的代價。BKA實際上是利用了MRR特性(MultiRangeRead)，訪問資料之前，先將主鍵排序，然後再訪問。主鍵排序的快取大小通過引數read_rnd_buffer_size控制。

總結

MySQL8.0以後，Server層程式碼做了大量的重構，雖然優化器相對於Oracle還有很大差距，但一直在進步。HashJoin的支援使得MySQL優化器有更多選擇，SQL的執行路徑也能做到更優，尤其是對於等值join的場景。雖然MySQL之前對於Join做過若干優化，比如NBLJ，INLJ以及BKA等，但這些代替不了HashJoin的作用。一個好用的資料庫就應該具備豐富的基礎能力，利用優化器分析出合適場景，然後拿出對應的基礎能力以最高效的方式響應請求。

參考文件

https://en.wikipedia.org/wiki/Hash_join

https://mysqlserverteam.com/hash-join-in-mysql-8/

https://dev.mysql.com/worklog/task/?id=2241

https://www.cnblogs.com/qixinbo/p/10524142.html

https://zhuanlan.zhihu.com/p/3504