MySQL8.0 新特性 Hash Join

時間 2019-11-30

標籤 mysql8.0 mysql 特性 hash join 欄目 MySQL 简体版

原文原文鏈接

概述&背景

MySQL一直被人詬病沒有實現HashJoin，最新發布的8.0.18已經帶上了這個功能，使人欣喜。有時候在想，MySQL爲何一直不支持HashJoin呢？我想多是由於MySQL多用於簡單的OLTP場景，而且在互聯網應用居多，需求沒那麼緊急。另外一方面多是由於之前徹底靠社區，這種演進速度畢竟有限，Oracle收購MySQL後，MySQL的發版演進速度明顯加快了不少。html

HashJoin自己算法實現並不複雜，要說複雜，多是優化器配套選擇執行計劃時，是否選擇HashJoin，選擇外表，內表可能更復雜一點。無論怎樣如今已經有了HashJoin，優化器在選擇Join算法時又多了一個選擇。MySQL本着實用主義，相信這個功能加強也迴應了一些質疑，有些功能不是沒有能力作好，而是有它的優先級。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算法的實現。sql

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官方博客oop

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

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的做用。一個好用的數據庫就應該具有豐富的基礎能力，利用優化器分析出合適場景，而後拿出對應的基礎能力以最高效的方式響應請求。