MySQL 8.0发布，你熟悉又陌生的Hash Join？

时间  2020-01-17
标签 mysql 8.0 发布 熟悉 陌生 hash join 栏目 MySQL 繁體版
原文   原文链接

昨天下午在查资料的时候，无心间点到了MySQL的官网。发现MySQL发布了一个新版本。html

Mysql这个数据库有没有人不熟悉？不用的？没有吧。mysql

2019年底，MySQL发布的8.0.18 GA版本，带来了一些新特性和加强功能。其中最引人注目的莫过于多表链接查询支持Hash Join。面试

仍是老样子，建议英文好的同窗直接看这里：https://dev.mysql.com/doc/refman/8.0/en/hash-joins.htmlsql

关于MySQL Hash Join的特性介绍：数据库

  • 一、对于大数据量的表关联，HJ(Hash Join)速度将明显比NL(Nested Loop)快不少
  • 二、在内存中处理
  • 三、必要状况下，会使用磁盘空间
  • 四、用于内链接，可扩展到外链接、半链接和反链接
  • 五、替换查询计划中的Block Nested Loop
  • 六、能够经过HINT强制SQL走HJ或者NL

有的同窗可能已经懵逼了。什么是Hash Join？什么是NL？HINT又是什么鬼？服务器

第一部分先作一个简单的科普架构

首先，在多表联合查询的时候，若是咱们查看它的执行计划，就会发现里面有多表之间的链接方式。多表之间的链接有三种方式：Nested Loops，Hash Join 和 Sort Merge Join。并发

确定有人说，阿里巴巴规范上都说了，并发状况下不能用多表查询。你有多大并发？任何一个系统的后台都会用到多表联合查询。oop

Hash Join 在Spark 和 Flink的SQL部分进行Join的时候都会被用到，以前咱们发过一篇文章：测试

[Spark SQL 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中会起到特殊的做用，是对数据库的提示，表示但愿数据库按照个人提示进行执行。这里就不举例了。

书归正文，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的执行计划：

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。

此外，多个表之间使用等值链接的的查询也会进行这种优化。例如如下查询：

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: <not executable by iterator executor>

复制代码

咱们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查询岂不是美滋滋？

两种方式任选其一：

  • 全局设置服务器系统变量hash_join=on
  • 在SQL中使用Hint指定 HASHJOIN 或者 NOHASH_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: <not executable by iterator executor>

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 is not null)  (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 秒。因此在咱们这个场景中的测试结果以下：

file

再增长一个 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的强大了吧？你学到了吗？

关注个人公众号，后台回复【JAVAPDF】获取200页面试题！5万人关注的大数据成神之路，不来了解一下吗？5万人关注的大数据成神之路，真的不来了解一下吗？5万人关注的大数据成神之路，肯定真的不来了解一下吗？

欢迎您关注《大数据成神之路》

大数据技术与架构

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程