MySQL 三表 JOIN 是怎么个流程呢?效率又如何?

原创
2023/12/28 09:48
阅读数 344

常听说 MySQL 中三表 JOIN 的执行流程并不是前两张表 JOIN 得出结果,再与第三张表进行 JOIN;而是三表嵌套的循环连接。

作者:胡呈清,爱可生 DBA 团队成员,擅长故障分析、性能优化,个人博客:[简书 | 轻松的鱼],欢迎讨论。

爱可生开源社区出品,原创内容未经授权不得随意使用,转载请联系小编并注明来源。

本文共 2000 字,预计阅读需要 8 分钟。

那这个三表嵌套的循环连接具体又是个什么流程呢?与前两张表 JOIN 得出结果再与第三张表进行 JOIN 的执行效率相比如何呢?下面通过一个例子来分析分析。

前提

关联字段无索引的情况下强制使用索引嵌套循环连接算法,目的是更好的观察扫描行数。

set optimizer_switch='block_nested_loop=off';

表结构和数据如下:

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;
create table t3 like t2;
insert into t1 (select * from t2 where id<=100);
insert into t3 (select * from t2 where id<=200);

示例 SQL:

select * from t1 join t2 on t1.b=t2.b  join t3 on t1.b=t3.b where t1.a<21;

通过扫描行数分析 JOIN 过程

通过 slow log 得知一共扫描 24100 行:

# Query_time: 0.016162  Lock_time: 0.000249 Rows_sent: 20  Rows_examined: 24100
SET timestamp=1617348099;
select * from t1 join t2 on t1.b=t2.b  join t3 on t1.b=t3.b where t1.a<21;

执行计划显示用的索引嵌套循环连接算法:

mysql> explain select * from t1 join t2 on t1.b=t2.b  join t3 on t1.b=t3.b where t1.a<21;
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | t1    | NULL       | ALL  | a             | NULL | NULL    | NULL |  100 |    20.00 | Using where |
|  1 | SIMPLE      | t3    | NULL       | ALL  | NULL          | NULL | NULL    | NULL |  200 |    10.00 | Using where |
|  1 | SIMPLE      | t2    | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 1000 |    10.00 | Using where |
+----+-------------+-------+------------+------+---------------+------+---------+------+------+----------+-------------+

扫描行数构成:

  • t1 扫描 100行;
  • t3 扫描 20*200=4000 行;
  • t2 扫描 20*1000=20000 行。

总行数=100+4000+20000=24100。

从这个结果来看,JOIN 过程像是先 t1t3 表 JOIN 得出 20 行中间结果,再与 t2 进行 JOIN 得出结果。这结论与我们通常认为的三表 JOIN 实际上是三表嵌套的循环连接不一样,接着往下看。

通过执行成本分析 JOIN 过程

查看执行计划成本:

mysql> explain format=json select * from t1 join t2 on t1.b=t2.b join t3 on t1.b=t3.b where t1.a<21\G

其他信息:

  • t1 表 100 行,只有 1 个数据页(可通过 mysql.innodb_table_stats);
  • t2 表 1000 行,有 4 个数据页;
  • t3 表 200 行,只有 1 个数据页;
  • io_block_read_cost=1.0,成本常数(MySQL 5.7):读取一个页面花费的成本默认是 1.0;
  • row_evaluate_cost=0.2,成本常数(MySQL 5.7):读取以及检测一条记录是否符合搜索条件的成本默认是 0.2。

t1 是驱动表,全表扫描。

  • 扫描 100 行;
  • 预估满足条件的只有 20%,即 100 * 20%=20,即 t1 的扇出。

IO 成本=1 * 1.0=1

CPU 成本=100 * 0.2=20

扫描 t1 总成本=21

t1 表扫描结果

t3 是被驱动表,全表扫描

  • 每次扫描 200 行;
  • 因为驱动表扇出为 20,所以要查找 20 次 t3,总共会扫描 20 * 200=4000 行;
  • 预估满足条件的行只有扫描行数的 10%,即 4000 * 10%=400,即为 t1 join t3 后的扇出,即 rows_produced_per_json。

IO 成本=1 * 1.0=1

CPU 成本=200 * 0.2=40

扫描 t3 表总成本=驱动表扇出 * (IO 成本+CPU 成本)=20 * (1+40)=820

阶段性总成本=21+820=841

此处 eval_cost=80,实则为驱动表扇出 被驱动每次扫描行数*filtered*成本常数,即 20 * 200 * 10% * 0.2

简化公式为:eval_cost=rows_produced_per_json * 成本常数

t2 也是被驱动表,全表扫描

  • 每次查找扫描1000行;
  • 要查找 400 次,总共会扫描 400 * 1000=400000 行;
  • 预估满足条件的只有 10%,即 400000 * 10%=40000,即为 t2 的扇出,即 rows_produced_per_json

IO 成本=4 * 1.0=4

CPU 成本=1000 * 0.2=200

扫描 t2 表总成本=前 2 表 JOIN 的扇出 * (IO 成本+CPU 成本)=400 * (4+200)=81600

阶段性总成本=841+81600=82441

此处 eval_cost=8000,即 rows_produced_per_json*成本常数,即 40000*0.2

根据执行计划成本分析:

  • t1 表查找 1 次,每次扫描 100行;
  • t3 表查找 20 次,每次扫描 200 行;
  • t2 表查找 400 次,每次扫描 1000 行。

这样看,三表 JOIN 流程是:

  1. 全表扫描 t1,满足条件的有 20 行,先取第 1 行数据记为 R1;

  2. 从 R1 中取出 b 字段去 t3 表中查找;

  3. 取出 t3 中满足条件的行,跟 R1 组成一行,作为结果集的一部分,从结果集中取第 1 行数据记为 X1;

    a. 从 X1 中取出 b 字段去 t2 表中查找; b. 取出 t2 中满足条件的行,跟 X1 组成一行,作为结果集的一部分; c. 重复 a、b 步骤,直到结束。

  4. 重复 2、3 步骤,直到结束。

图示(这里展示的是索引嵌套循环算法时三表 JOIN 的流程,块循环嵌套算法不一样):

注意:由于造的数据比较特殊,所以第 3 步得出的中间结果集实际上只有 1 行,所以最终 t2 表的查找次数是 20 * 1=20,所以扫描总行数是 20 * 1000。所以单看 slow log 中显示的 24100 行,会误认为是先得出 t1t3 JOIN 的结果,再去和 t2 进行 JOIN。

当我调整 t3 的数据,删除 20 行,再插入 20 行,使满足 b<21 的数据翻倍,这样“第 3 步得出的中间结果集”变成 2 行:

mysql> delete from t3 where id>180;
Query OK, 20 rows affected (0.00 sec)
mysql> insert into t3 select * from t3 where b<21;
Query OK, 20 rows affected (0.00 sec)

再来看 slow log 中扫描的总行数为 44100,t1t3 的扫描行数不变,t2 的扫描行数变为 20 * 2* 1000=40000

# Query_time: 0.013848  Lock_time: 0.000100 Rows_sent: 40  Rows_examined: 44100
SET timestamp=1617354884;
select * from t1 join t2 on t1.b=t2.b  join t3 on t1.b=t3.b where t1.a<21;

为什么执行计划中分析得到的是 t2 表查找 400 次呢?

因为执行计划对 t1 JOIN t3 的扇出是个估算值,不准确。而 slow log 是真实执行后统计的,是个准确值。

为什么执行计划中,t2 表的执行次数是用“t1 join t3 的扇出”表示的?这不是说明 t1 先和 t3 JOIN,结果再和 t2 JOIN?

其实拆解来看,“三表嵌套循环” 和 “前两表 JOIN 的结果和第三张表 JOIN” 两种算法,成本是一样的,而且如果要按三表嵌套循环的方式展示每张表的成本将非常复杂,可读性不强。所以执行计划中这么表示没有问题。

总结

总的来说,对于三表 JOIN 或者多表 JOIN 来说,“三表嵌套循环” 和 “先两表 JOIN,结果和第三张表 JOIN” 两种算法,成本是一样的。

当被驱动表的关联字段不是唯一索引,或者没有索引,每次扫描行数会大于 1 时,其扇出误差会非常大。比如在上面的示例中:

t3 表实际的扇出只有 20,但优化器估算值是总扫描行数的 10%,由于 t3 表的关联字段没有索引,所以每次都要全表扫描 200 行,总的扫描行数=20 * 200=4000,扇出=4000 * 10%=400,比实际的 20 大了 20 倍。尤其对于后续表的 JOIN 来说,成本估算会产生更严重的偏差。

如果是 LEFT JOIN,每个被驱动表的 filtered 都会被优化器认定为 100%,误差更大!

通常建议 JOIN 不超过两张表,就是因为优化器估算成本误差大导致选择不好的执行计划,如果要用,一定要记住:关联字段必须要有索引,最好是唯一性或者基数大的索引。

补充:MySQL 8.0 有 HASH JOIN 后这种情况会好很多。

更多技术文章,请访问:https://opensource.actionsky.com/

关于 SQLE

SQLE 是一款全方位的 SQL 质量管理平台,覆盖开发至生产环境的 SQL 审核和管理。支持主流的开源、商业、国产数据库,为开发和运维提供流程自动化能力,提升上线效率,提高数据质量。

SQLE 获取

类型 地址
版本库 https://github.com/actiontech/sqle
文档 https://actiontech.github.io/sqle-docs/
发布信息 https://github.com/actiontech/sqle/releases
数据审核插件开发文档 https://actiontech.github.io/sqle-docs/docs/dev-manual/plugins/howtouse
展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部