MySQL join原理及优化-编程知识

MySQL的JOIN原理是基于索引和算法的。在执行JOIN查询时，MySQL会根据连接字段上的索引来查找匹配的记录。
这种算法在链接查询的时候，驱动表会根据关联字段的索引进行查找，当在索引上找到了符合的值，再回表进行查询，也就是只有当匹配到索引以后才会进行回表。

在进行JOIN查询时，MySQL还采用了一些优化策略来提高查询性能，例如使用嵌套循环连接算法（Nested-Loop Join）和索引优化技术。

嵌套循环连接算法按照指定的连接方式执行查询，不会自己选择驱动表。当连接字段上有索引时，MySQL会使用索引来加速查找过程

Join 算法

使用 left join 时，左边的表不一定是驱动表，优化器可能会将语句优化为join。如果需要 left join 的语义，就不能把被驱动表的字段放在 where 条件里面做等值判断或不等值判断，必须都写在 on 里面

为了便于量化分析各种Join 算法，以下创建两个表 t1 和 t2 来说明

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()
begindeclare i int;set i=1;while(i<=1000)doinsert into t2 values(i, i, i);set i=i+1;end while;
end;;
delimiter ;
call idata();create table t1 like t2;
insert into t1 (select * from t2 where id<=100)

可以看到，这两个表都有一个主键索引 id 和一个索引 a，字段 b 上无索引。存储过程 idata() 往表 t2 里插入了 1000 行数据，在表 t1 里插入的是 100 行数据

Index Nested-Loop Join

select * from t1 straight_join t2 on (t1.a=t2.a);

为了便于分析执行过程中的性能问题，我改用straight_join让 MySQL 使用固定的连接方式执行查询，这样优化器只会按照我们指定的方式去 join。在这个语句里，t1 是驱动表，t2 是被驱动表

如果直接使用 join 语句，MySQL 优化器可能会选择表 t1 或 t2 作为驱动表，这样会影响我们分析 SQL 语句的执行过程

INL算法步骤为先遍历表 t1，然后根据从表 t1 中取出的每行数据中的 a 值，去表 t2 中查找满足条件的记录。在形式上，这个过程就跟我们写程序时的嵌套查询类似，并且可以用上被驱动表的索引

Index Nested-Loop Join 算法的执行流程

查询复杂度

在INL算法程中，驱动表是走全表扫描，而被驱动表是走树搜索

假设被驱动表的行数是 M。每次在被驱动表查一行数据，要先搜索索引 a，再搜索主键索引。每次搜索一棵树近似复杂度是以 2 为底的 M 的对数，记为 $log_2M$ ，所以在被驱动表上查一行的时间复杂度是 $2 * log_2M$ 。

假设驱动表的行数是 N，执行过程就要扫描驱动表 N 行，然后对于每一行，到被驱动表上匹配一次。

因此整个执行过程，近似复杂度是 $N + N* 2*log_2M$

Simple Nested-Loop Join

select * from t1 straight_join t2 on (t1.a=t2.b);

若把SQL 语句改成这样，由于表 t2 的字段 b 上没有索引，因此再用上图的执行流程时，每次到 t2 去匹配的时候，就要做一次全表扫描。复杂度是 M * N。这个 SQL 请求就要扫描表 t2 多达 100 次，总共扫描 100*1000=10 万行

MySQL 没有使用 Simple Nested-Loop Join 算法，而是使用了另一个叫作“Block Nested-Loop Join”的算法，简称 BNL

Block Nested-Loop Join

join_buffer是一个用于存储连接操作（join）中临时数据的缓冲区。当执行连接操作时，MySQL将从连接的表中读取数据，并临时存储在join_buffer中，以便执行连接操作的计算和比较

当被驱动表上没有可用的索引，算法的流程是这样的

把表 t1 的数据读入线程内存 join_buffer 中，由于我们这个语句中写的是select *，因此是把整个表 t1 放入了内存；
扫描表 t2，把表 t2 中的每一行取出来，跟 join_buffer 中的数据做对比，满足 JOIN 条件的，作为结果集的一部分返回

Block Nested-LOOP JOIN 算法的执行流程

可以看到，在这个过程中，对表 t1 和 t2 都做了一次全表扫描，因此总的扫描行数是 1100。由于 join_buffer 是以无序数组的方式组织的，因此对表 t2 中的每一行，都要做 100 次判断，总共需要在内存中做的判断次数是：100*1000=10 万次

join_buffer 的大小是由参数 join_buffer_size 设定的，默认值是 256k。 如果放不下表 t1 的所有数据话，策略很简单，就是分块放

假设，驱动表的数据行数是 N，需要分 K 段才能完成算法流程，被驱动表的数据行数是 M。

注意，这里的 K 不是常数，N 越大 K 就会越大，因此把 K 表示为λ*N，显然λ的取值范围是 (0,1)。

所以，在这个算法的执行过程中：

扫描行数是 N+λNM；
内存判断 N*M 次

SNL与BNL对比

SNL/BNL 算法对系统的影响主要包括三个方面：

可能会多次扫描被驱动表，占用磁盘 IO 资源；
判断 join 条件需要执行 M*N 次对比（M、N 分别是两张表的行数），如果是大表就会占用非常多的 CPU 资源；
可能会导致 Buffer Pool 的热数据被淘汰，影响内存命中率

大表 join 操作虽然对 IO 有影响，但是在语句执行结束后，对 IO 的影响也就结束了。但是，对 Buffer Pool 的影响就是持续性的，需要依靠后续的查询请求慢慢恢复内存命中率。

为了减少这种影响，可以考虑增大join_buffer_size的值，减少对被驱动表的扫描次数

BNL 算法的执行逻辑是：将驱动表的数据全部读入内存 join_buffer 中，然后将连接操作划分为多个块，每个块包含一定数量的记录。每一行数据都跟 join_buffer 中的数据进行匹配，匹配成功则作为结果集的一部分返回。
SNL 算法的执行逻辑是：顺序取出驱动表中的每一行数据，到被驱动表去做全表扫描匹配，匹配成功则作为结果集的一部分返回

BNL算法在处理连接操作时采用了块状处理和索引优化技术(转为BKA)，使得它在处理大规模数据时能够比SNL算法更快地完成查询操作

Batched Key Access

理解了 MRR 性能提升的原理，我们就能理解 MySQL 在 5.6 版本后开始引入的 Batched KEY Access(BKA) 算法了。这个 BKA 算法，其实就是对 NLJ 算法的优化

join_buffer 在 BNL 算法里的作用，是暂存驱动表的数据。在 NLJ 算法复用 join_buffer ，就优化为BKA 算法了

Batched KEY Access 流程

图中在 join_buffer 中放入的数据是 R1~R100，表示的是只会取查询需要的字段。当然，如果 JOIN buffer 放不下 R1~R100 的所有数据，就会把这 100 行数据分成多段执行上图的流程

使用 BKA 优化算法，需要在执行 SQL 语句之前，先设置

set optimizer_switch='mrr=on,mrr_cost_based=off,batched_key_access=on';

其中，前两个参数的作用是要启用 MRR。这么做的原因是，BKA 算法的优化要依赖于 MRR

Join 优化

Multi-Range Read 优化

Multi-Range Read优化的目的就是为了减少磁盘的随机访问，并且将随机访问转化为较为顺序的数据访问，这对于IO-bound类型的SQL查询语句可带来性能极大的提升。Multi-Range Read优化可适用于range，ref，eq_ref类型的查询

MRR优化的优点及工作方式详见 MRR优化

如果随着 a 的值递增顺序查询的话，id 的值就变成随机的，那么就会出现随机访问，性能相对较差。而通过MRR优化后，会将满足条件的记录id值放入read_rnd_buffer中，再讲id进行递增排序后依次查记录并返回结果。执行流程如下图所示

因为大多数的数据都是按照主键递增顺序插入得到的，所以我们可以认为，如果按照主键的递增顺序查询的话，对磁盘的读比较接近顺序读，能够提升读性能

MRR优化后的执行流程

MRR优化后的explain 结果

BNL 转 BKA

select * from t1 join t2 on (t1.b=t2.b) where t2.b>=1 and t2.b<=2000;

对于表 t2 的每一行，判断 JOIN 是否满足的时候，都需要遍历 join_buffer 中的所有行。因此判断等值条件的次数是 1000*100 万 =10 亿次，这个判断的工作量很大

对于这种不适合在被驱动表上建索引的情况，可以考虑使用临时表

大致思路是：

把表 t2 中满足条件的数据放在临时表 tmp_t 中；
为了让 JOIN 使用 BKA 算法，给临时表 tmp_t 的字段 b 加上索引；
让表 t1 和 tmp_t 做 JOIN 操作

create temporary table temp_t(id int primary key, a int, b int, index(b))engine=innodb;
insert into temp_t select * from t2 where b>=1 and b<=2000;
select * from t1 join temp_t on (t1.b=temp_t.b);

总体来看，不论是在原表上加索引，还是用有索引的临时表，我们的思路都是让 JOIN 语句能够用上被驱动表上的索引，来触发 BKA 算法，提升查询性能

Hash join

业务多次查询，再到hash结构的数据表中寻找匹配的数据

对于上面计算 10 亿次那个操作，看上去有点儿傻。如果 join_buffer 里面维护的不是一个无序数组，而是一个哈希表的话，那么就不是 10 亿次判断，而是 100 万次 HASH 查找

然而 MySQL 的优化器和执行器一直被诟病的一个原因：不支持哈希 join。所以将两个表的数据分别查询，在业务中组合匹配的效率其实更高

流程大致如下：

select * from t1;取得表 t1 的全部 1000 行数据，在业务端存入一个 HASH 结构，比如 C++ 里的 set、PHP 的数组这样的数据结构。
select * from t2 where b>=1 and b<=2000; 获取表 t2 中满足条件的 2000 行数据。
把这 2000 行数据，一行一行地取到业务端，到 HASH 结构的数据表中寻找匹配的数据。满足匹配的条件的这行数据，就作为结果集的一行。