工作中,大部分业务场景,都是多张表关联才会满足,很少有单张表的操作,这篇文章将会介绍多表关联种join的一些优化方法
为了方便理解,首先创建测试表并写入测试数据,语句如下:
CREATE DATABASE muke; /* 创建测试使用的database,名为muke */
use muke; /* 使用muke这个database */
drop table if exists t1; /* 如果表t1存在则删除表t1 */
CREATE TABLE `t1` ( /* 创建表t1 */
`id` int(11) NOT NULL auto_increment,
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL,
`create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '记录创建时间',
`update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
COMMENT '记录更新时间',
PRIMARY KEY (`id`),
KEY `idx_a` (`a`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
drop procedure if exists insert_t1; /* 如果存在存储过程insert_t1,则删除 */
delimiter ;;
create procedure insert_t1() /* 创建存储过程insert_t1 */
begin
declare i int; /* 声明变量i */
set i=1; /* 设置i的初始值为1 */
while(i<=10000)do /* 对满足i<=10000的值进行while循环 */
insert into t1(a,b) values(i, i); /* 写入表t1中a、b两个字段,值都为i当前的值 */
set i=i+1; /* 将i加1 */
end while;
end;;
delimiter ; /* 创建批量写入10000条数据到表t1的存储过程insert_t1 */
call insert_t1(); /* 运行存储过程insert_t1 */
drop table if exists t2; /* 如果表t2存在则删除表t2 */
create table t2 like t1; /* 创建表t2,表结构与t1一致 */
insert into t2 select * from t1 limit 100; /* 将表t1的前100行数据导入到t2 */
Nested-Loop Join(NLJ) 算法
Block Nested-Loop Join ()算法
Batched Key Access 算法 ()
select * from t1 inner join t2 on t1.a = t2.a; /* sql1 */
怎么确定这条 SQL 使用的是 NLJ 算法?
我们先来看下 sql1 的执行计划:
所以使用 inner join 时,前面的表并不一定就是驱动表。
sql1 的大致流程如下:
1 从表 t2 中读取一行数据;
2 从第 1 步的数据中,取出关联字段 a,到表 t1 中查找;
3 取出表 t1 中满足条件的行,跟 t2 中获取到的结果合并,作为结果返回给客户端;
4 重复上面 3 步。
在这个过程中会读取 t2 表的所有数据,因此这里扫描了 100 行,然后遍历这 100 行数据中字段 a 的值,根据 t2 表中 a 的值索引扫描 t1 表中的对应行,这里也扫描了 100 行。因此整个过程扫描了 200 行。
表 t1 和表 t2 中的 b 字段都没有索引
select * from t1 inner join t2 on t1.b = t2.b; /* sql2 */
我们再看下 sql2 的执行流程:
1 把 t2 的所有数据放入到 join_buffer 中
2 把表 t1 中每一行取出来,跟 join_buffer 中的数据做对比
3 返回满足 join 条件的数据
在这个过程中,对表 t1 和 t2 都做了一次全表扫描,因此扫描的总行数为10000(表 t1 的数据总量) + 100(表 t2 的数据总量) = 10100。并且 join_buffer 里的数据是无序的,因此对表 t1 中的每一行,都要做 100 次判断,所以内存中的判断次数是 100 * 10000= 100 万次。
下面我们来回答上面提出的一个问题:
如果被驱动表的关联字段没索引,为什么会选择使用 BNL 算法而不继续使用 Nested-Loop Join 呢?
在被驱动表的关联字段没索引的情况下,比如 sql2:
如果使用 Nested-Loop Join,那么扫描行数为 100 * 10000 = 100万次,这个是磁盘扫描。
如果使用 BNL,那么磁盘扫描是 100 + 10000=10100 次,在内存中判断 100 * 10000 = 100万次。
因此对于 MySQL 的关联查询,如果被驱动表的关联字段没索引,会使用 BNL 算法。
NLJ 的关键思想是:被驱动表的关联字段有索引。
BNL 的关键思想是:把驱动表的数据批量提交一部分放到 join_buffer 中。
BKA
其原理是:
1 将驱动表中相关列放入 join_buffer 中
2 批量将关联字段的值发送到 Multi-Range Read(MRR) 接口
3 MRR 通过接收到的值,根据其对应的主键 ID 进行排序,然后再进行数据的读取和操作
4 返回结果给客户端
下面尝试开启 BKA :
set optimizer_switch='mrr=on,mrr_cost_based=off,batched_key_access=on';
这里对上面几个参数做下解释:
mrr=on 开启 mrr
mrr_cost_based=off 不需要优化器基于成本考虑使用还是不使用 MRR,也就是一直使用 MRR
batched_key_access=on 开启 BKA
然后再看 sql1 的执行计划:
explain select * from t1 inner join t2 on t1.a = t2.a;
关联字段添加索引
通过上面的内容,我们知道了 BNL、NLJ 和 BKA 的原理,因此让 BNL变成 NLJ 或者 BKA,可以提高 join 的效率
因此建议在被驱动表的关联字段上添加索引,让 BNL变成 NLJ 或者 BKA ,可明显优化关联查询。
小表做驱动表
所以在写 SQL 时,如果确定被关联字段有索引的情况下,建议用小表做驱动表。
我们来看下以 t2 为驱动表的 SQL:
select * from t2 straight_join t1 on t2.a = t1.a;
这里使用 straight_join 可以固定连接方式,让前面的表为驱动表。
再看下以 t1 为驱动表的 SQL:
select * from t1 straight_join t2 on t1.a = t2.a;
多数情况我们可以通过在被驱动表的关联字段上加索引来让 join 使用 NLJ 或者 BKA,但有时因为某条关联查询只是临时查一次,如果再去添加索引可能会浪费资源,那么有什么办法优化呢?
这里提供一种创建临时表的方法。
我们一起测试下:
比如下面这条关联查询:
select * from t1 join t2 on t1.b= t2.b;
我们看下执行计划:
现在用临时表的方法对这条 SQL 进行优化:
首先创建临时表 t1_tmp,表结构与表 t1 一致,只是在关联字段 b 上添加了索引。
CREATE TEMPORARY TABLE `t1_tmp` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`a` int(11) DEFAULT NULL,
`b` int(11) DEFAULT NULL,
`create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '记录创建时间',
`update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '记录更新时间',
PRIMARY KEY (`id`),
KEY `idx_a` (`a`),
KEY `idx_b` (b)
) ENGINE=InnoDB ;
把 t1 表中的数据写入临时表 t1_tmp 中:
insert into t1_tmp select * from t1;
执行 join 语句:
select * from t1_tmp join t2 on t1_tmp.b= t2.b;
我们再看下执行计划:
所以当遇到 BNL 的 join 语句,如果不方便在关联字段上添加索引,不妨尝试创建临时表,然后在临时表中的关联字段上添加索引,然后通过临时表来做关联查询。
本节首先讲到了 NLJ 、BNL、和 BKA 这几种 join 算法的原理,然后通过认识这些算法,从而引申出 join 语句的一些优化技巧,比如关联字段添加索引、小表做驱动表和创建临时表等方法。
该文为本人学习的笔记,方便以后自己复习。参考 《MySQL 5.7 Reference Manual》 8.2.1.6
Nested-Loop Join
Algorithms:https://dev.mysql.com/doc/refman/5.7/en/nested-loop-joins.html
8.2.1.10 Multi-Range Read
Optimization:https://dev.mysql.com/doc/refman/5.7/en/mrr-optimization.html
8.2.1.11 Block Nested-Loop and Batched Key Access
Joins:https://dev.mysql.com/doc/refman/5.7/en/bnl-bka-optimization.html
慕课网专栏:https://www.imooc.com/read/43 取其精华整合而成。
因篇幅问题不能全部显示,请点此查看更多更全内容