MySQL8.0發佈，你熟悉又陌生的Hash Join？

時間  2021-04-04
標籤 html mysql sql 數據庫 服務器 架構 併發 ide oop 測試 欄目 MySQL 简体版
原文   原文鏈接

MySQL8.0發佈，你熟悉又陌生的Hash Join？

大數據技術與架構 大數據技術與架構html

昨天下午在查資料的時候，無心間點到了MySQL的doc。發現MySQL發佈了一個新版本。
Mysql這個數據庫有沒有人不熟悉？不用的？沒有吧。
2019年底，MySQL發佈的8.0.18 GA版本，帶來了一些新特性和加強功能。其中最引人注目的莫過於多表鏈接查詢支持Hash Join。
仍是老樣子，建議英文好的同窗直接看這裏：https://dev.mysql.com/doc/refman/8.0/en/hash-joins.html
關於MySQL Hash Join的特性介紹：mysql

  • 對於大數據量的表關聯，HJ(Hash Join)速度將明顯比NL(Nested Loop)快不少
  • 在內存中處理
  • 必要狀況下，會使用磁盤空間
  • 用於內鏈接，可擴展到外鏈接、半鏈接和反鏈接
  • 替換查詢計劃中的Block Nested Loop
  • 能夠經過HINT強制SQL走HJ或者NL

有的同窗可能已經懵逼了。
什麼是Hash Join？
什麼是NL？
HINT又是什麼鬼？
跟我有什麼關係？sql

第一部分先作一個簡單的科普

首先，在多表聯合查詢的時候，若是咱們查看它的執行計劃，就會發現裏面有多表之間的鏈接方式。多表之間的鏈接有三種方式：Nested Loops，Hash Join 和 Sort Merge Join。
確定有人說，阿里巴巴規範上都說了，併發狀況下不能用多表查詢。你有多大併發？任何一個系統的後臺都會用到多表聯合查詢。
Hash Join 在Spark 和 Flink的SQL部分進行Join的時候都會被用到，以前咱們發過一篇文章，《SparkSQL的3種Join實現》。
Hash Join散列鏈接是CBO作大數據集鏈接時的經常使用方式，並且一般適合大小表之間進行Join。通常來講，使用小表利用鏈接鍵（JOIN KEY）在內存中創建散列表，將列數據存儲到hash列表中，而後掃描較大的表，一樣對JOIN KEY進行HASH後探測散列表，找出與散列表匹配的行。
有的同窗又懵逼了。CBO是什麼？這裏咱們就不展開了，簡單的說CBO是一種SQL優化方式，它會根據真實的數據狀況，評估執行計劃，選擇代價最小的執行計劃。
什麼是執行計劃？百度去吧..
那什麼是Nested Loops？簡單的說就是兩層循環，用第一張表作Outter Loop，第二張表作Inner Loop，Outter Loop的每一條記錄跟Inner Loop的記錄做比較，找出符合條件的數據。固然Nested Loops有多種狀況。咱們舉個最簡單的例子，僞代碼以下：數據庫

for (r in R) {
        for (s in S) {
            if (r satisfy condition s) {
                output <r, s>;
            }
        }
    }

什麼是Hint？Hint這個英文單詞是提示的意思。簡單的說，Hint特別像咱們在開發代碼時候的註釋，代碼中的註釋是提示開發者或者其餘人這段代碼的意思。那麼這個Hint在SQL中會起到特殊的做用，是對數據庫的提示，表示但願數據庫按照個人提示進行執行SQL。這裏就不舉例了。服務器

書歸正文，Hash Join在新版MySQL中如何使用？

咱們直接用官網的例子。
假設咱們有三張表以下：架構

CREATE TABLE t1 (c1 INT, c2 INT);
CREATE TABLE t2 (c1 INT, c2 INT);
CREATE TABLE t3 (c1 INT, c2 INT);

有一個簡單的表關聯查詢：併發

SELECT *
    FROM t1
    JOIN t2
        ON t1.c1=t2.c1;

咱們使用EXPLAIN FORMAT=TREE命令能夠看到上面SQL的執行計劃：ide

mysql> EXPLAIN FORMAT=TREE
    -> SELECT *
    ->     FROM t1
    ->     JOIN t2
    ->         ON t1.c1=t2.c1\G
*************************** 1. row ***************************
EXPLAIN: -> Inner hash join (t2.c1 = t1.c1)  (cost=0.70 rows=1)
    -> Table scan on t2  (cost=0.35 rows=1)
    -> Hash
        -> Table scan on t1  (cost=0.35 rows=1)

咱們看到關鍵詞Inner hash join則表明這條SQL使用了Hash Join。
此外，多個表之間使用等值鏈接的的查詢也會進行這種優化。例如如下查詢：oop

SELECT *
    FROM t1
    JOIN t2
        ON (t1.c1 = t2.c1 AND t1.c2 < t2.c2)
    JOIN t3
        ON (t2.c1 = t3.c1);

經過EXPLAIN FORMAT=TREE命令的輸出進行查看，咱們同時能夠發現非等值鏈接的條件會在最後變成過濾器。測試

mysql> EXPLAIN FORMAT=TREE
    -> SELECT *
    ->     FROM t1
    ->     JOIN t2
    ->         ON (t1.c1 = t2.c1 AND t1.c2 < t2.c2)
    ->     JOIN t3
    ->         ON (t2.c1 = t3.c1)\G
*************************** 1. row ***************************
EXPLAIN: -> Inner hash join (t3.c1 = t1.c1)  (cost=1.05 rows=1)
    -> Table scan on t3  (cost=0.35 rows=1)
    -> Hash
        -> Filter: (t1.c2 < t2.c2)  (cost=0.70 rows=1)
            -> Inner hash join (t2.c1 = t1.c1)  (cost=0.70 rows=1)
                -> Table scan on t2  (cost=0.35 rows=1)
                -> Hash
                    -> Table scan on t1  (cost=0.35 rows=1)

從上面的日誌也能看到 若是你的SQL包含多個等值鏈接，那麼MySQL會使用多個Hash Join。
可是，注意啦！若是你的SQL中on條件中不是等值鏈接，那麼不會採用Hash Join。
例如：

mysql> EXPLAIN FORMAT=TREE
    ->     SELECT *
    ->         FROM t1
    ->         JOIN t2
    ->             ON (t1.c1 = t2.c1)
    ->         JOIN t3
    ->             ON (t2.c1 < t3.c1)\G
*************************** 1. row ***************************
EXPLAIN: <notexecutablebyiteratorexecutor>

咱們EXPLAIN一下看看：

mysql> EXPLAIN
    ->     SELECT *
    ->         FROM t1
    ->         JOIN t2
    ->             ON (t1.c1 = t2.c1)
    ->         JOIN t3
    ->             ON (t2.c1 < t3.c1)\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t1
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 1
     filtered: 100.00
        Extra: NULL
*************************** 2. row ***************************
           id: 1
  select_type: SIMPLE
        table: t2
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 1
     filtered: 100.00
        Extra: Using where; Using join buffer (Block Nested Loop)
*************************** 3. row ***************************
           id: 1
  select_type: SIMPLE
        table: t3
   partitions: NULL
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 1
     filtered: 100.00
        Extra: Using where; Using join buffer (Block Nested Loop)

看到了吧，MySQL這時候就會選擇Nested Loop。
笛卡爾積查詢也一樣可使用HJ：

mysql> EXPLAIN FORMAT=TREE
    -> SELECT *
    ->     FROM t1
    ->     JOIN t2
    ->     WHERE t1.c2 > 50\G
*************************** 1. row ***************************
EXPLAIN: -> Inner hash join  (cost=0.70 rows=1)
    -> Table scan on t2  (cost=0.35 rows=1)
    -> Hash
        -> Filter: (t1.c2 > 50)  (cost=0.35 rows=1)
            -> Table scan on t1  (cost=0.35 rows=1)

注意看重點！

默認配置時，MySQL 會盡量的使用Hash Join。 同時也提供了兩種控制是否使用Hash Join的方法。 好比我就是不喜歡HJ，我就喜歡NL的龜速Join，而後項目經理讓優化時候再打開HJ查詢豈不是美滋滋？你說HJ跟你有沒有關係圖片

兩種方式任選其一：

  • 全局設置服務器系統變量hash_join=on
  • 在SQL中使用Hint指定 HASH_JOIN 或者 NO_HASH_JOIN
    更爲牛逼的是，HJ自身不受索引的影響，意思就是即便沒有進行索引優化，HJ依然速度很快。

下面是我找了一個網上其餘人的測試，展現一下HJ的強大。

首先分別爲 t一、t2 和 t3 生成 1000000 條記錄：

set join_buffer_size=2097152000;

SET @@cte_max_recursion_depth = 99999999;

INSERT INTO t1
-- INSERT INTO t2
-- INSERT INTO t3
WITH RECURSIVE t AS (
  SELECT 1 AS c1, 1 AS c2
  UNION ALL
  SELECT t.c1 + 1, t.c1 * 2
    FROM t
   WHERE t.c1 < 1000000
)
SELECT *
  FROM t;

沒有索引狀況下的 hash join：

mysql> EXPLAIN ANALYZE
    -> SELECT COUNT(*)
    ->   FROM t1
    ->   JOIN t2
    ->     ON (t1.c1 = t2.c1)
    ->   JOIN t3
    ->     ON (t2.c1 = t3.c1)\G
*************************** 1. row ***************************
EXPLAIN: -> Aggregate: count(0)  (actual time=22993.098..22993.099 rows=1 loops=1)
    -> Inner hash join (t3.c1 = t1.c1)  (cost=9952535443663536.00 rows=9952435908880402) (actual time=14489.176..21737.032 rows=1000000 loops=1)
        -> Table scan on t3  (cost=0.00 rows=998412) (actual time=0.103..3973.892 rows=1000000 loops=1)
        -> Hash
            -> Inner hash join (t2.c1 = t1.c1)  (cost=99682753413.67 rows=99682653660) (actual time=5663.592..12236.984 rows=1000000 loops=1)
                -> Table scan on t2  (cost=0.01 rows=998412) (actual time=0.067..3364.105 rows=1000000 loops=1)
                -> Hash
                    -> Table scan on t1  (cost=100539.40 rows=998412) (actual time=0.133..3395.799 rows=1000000 loops=1)

1 row in set (23.22 sec)

mysql> SELECT COUNT(*)
    ->   FROM t1
    ->   JOIN t2
    ->     ON (t1.c1 = t2.c1)
    ->   JOIN t3
    ->     ON (t2.c1 = t3.c1);
+----------+
| COUNT(*) |
+----------+
|  1000000 |
+----------+
1 row in set (12.98 sec)

實際運行花費了 12.98 秒。這個時候若是使用 block nested loop：

mysql> EXPLAIN FORMAT=TREE
    -> SELECT /*+  NO_HASH_JOIN(t1, t2, t3) */ COUNT(*)
    ->   FROM t1
    ->   JOIN t2
    ->     ON (t1.c1 = t2.c1)
    ->   JOIN t3
    ->     ON (t2.c1 = t3.c1)\G
*************************** 1. row ***************************
EXPLAIN: <notexecutablebyiteratorexecutor>

1 row in set (0.00 sec)

SELECT /*+  NO_HASH_JOIN(t1, t2, t3) */ COUNT(*)
  FROM t1
  JOIN t2
    ON (t1.c1 = t2.c1)
  JOIN t3
    ON (t2.c1 = t3.c1);

EXPLAIN 顯示沒法使用 hash join。查詢跑了幾十分鐘也沒有出結果，其中一個 CPU 使用率到了 100%；由於一直在執行嵌套循環（1000000 的 3 次方）。
再看有索引時的 block nested loop 方法，增長索引：

mysql> CREATE index idx1 ON t1(c1);
Query OK, 0 rows affected (7.39 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> CREATE index idx2 ON t2(c1);
Query OK, 0 rows affected (6.77 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> CREATE index idx3 ON t3(c1);
Query OK, 0 rows affected (7.23 sec)
Records: 0  Duplicates: 0  Warnings: 0

查看執行計劃並運行相同的查詢語句：

mysql> EXPLAIN ANALYZE
    -> SELECT COUNT(*)
    ->   FROM t1
    ->   JOIN t2
    ->     ON (t1.c1 = t2.c1)
    ->   JOIN t3
    ->     ON (t2.c1 = t3.c1)\G
*************************** 1. row ***************************
EXPLAIN: -> Aggregate: count(0)  (actual time=47684.034..47684.035 rows=1 loops=1)
    -> Nested loop inner join  (cost=2295573.22 rows=998412) (actual time=0.116..46363.599 rows=1000000 loops=1)
        -> Nested loop inner join  (cost=1198056.31 rows=998412) (actual time=0.087..25788.696 rows=1000000 loops=1)
            -> Filter: (t1.c1 isnotnull)  (cost=100539.40 rows=998412) (actual time=0.050..5557.847 rows=1000000 loops=1)
                -> Index scan on t1 using idx1  (cost=100539.40 rows=998412) (actual time=0.043..3253.769 rows=1000000 loops=1)
            -> Index lookup on t2 using idx2 (c1=t1.c1)  (cost=1.00 rows=1) (actual time=0.012..0.015 rows=1 loops=1000000)
        -> Index lookup on t3 using idx3 (c1=t1.c1)  (cost=1.00 rows=1) (actual time=0.012..0.015 rows=1 loops=1000000)

1 row in set (47.68 sec)

mysql> SELECT COUNT(*)
    ->   FROM t1
    ->   JOIN t2
    ->     ON (t1.c1 = t2.c1)
    ->   JOIN t3
    ->     ON (t2.c1 = t3.c1);
+----------+
| COUNT(*) |
+----------+
|  1000000 |
+----------+
1 row in set (19.56 sec)

實際運行花費了 19.56 秒。因此在咱們這個場景中的測試結果以下：

MySQL8.0發佈，你熟悉又陌生的Hash Join？

再增長一個 Oracle 12c 中無索引時 Hash Join 結果：1.282 s。 再增長一個 PostgreSQL 11.5 中無索引時 Hash Join 結果：6.234 s。 再增長一個 SQL Server 2017 中無索引時 Hash Join 結果：5.207 s。看到 Hash Join的強大了吧？你學到了嗎？

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程