大家好，我是 Snow Hide，作为《MySQL 实战》这个专栏的学员之一，这是我打卡的第 58 天，也是我第 120 次进行这种操作。
今天我温习了该专栏里一篇叫《答疑文章（三）：说一说这些好问题》的文章。
关键词总结：join 的写法（join 执行顺序的两个问题、BNL 算法时语句的执行流程）、Simple Nested Loop Join 的性能问题（BNL 算法的执行逻辑、MySQL 中索引结构和 Buffer Pool 的相关知识点）、distinct 和 group by 的性能（两条语句的执行流程）、备库自增主键问题。
所学总结：
join 的写法
create table a(f1 int, f2 int, index(f1))engine=innodb;
create table b(f1 int, f2 int)engine=innodb;
insert into a values(1,1),(2,2),(3,3),(4,4),(5,5),(6,6);
insert into b values(3,3),(4,4),(5,5),(6,6),(7,7),(8,8);
select * from a left join b on(a.f1=b.f1) and (a.f2=b.f2); /*Q1*/
select * from a left join b on(a.f1=b.f1) where (a.f2=b.f2);/*Q2*/
join 执行顺序的两个问题
- 如果用 left join 的话，左边的表一定是驱动表吗？
语句一返回的数据集是 6 行，表 a 中即使没有满足匹配条件的记录，查询结果中也会返回一行，并将表 b 的各个字段值填成 NULL。 - 如果两个表的 join 包含多个条件的等值匹配，是都要写到 on 里面呢，还是只把一个条件写到 on 里面，其他条件写到 where 部分？
语句二返回的是 4 行。从逻辑上可以这么理解，最后的两行，由于表 b 中没有匹配的字段，结果集里面 b.f2 的值是空，不满足 where 部分的条件判断，因此不能作为结果集的一部分。
BNL 算法时语句的执行流程
- 把表 a 的内容读入 join_buffer 中。因为是 select *，所以字段 f1 和 f2 都被放入 join_buffer；
- 顺序扫描表 b，对于每一行数据，判断 join 条件（也就是 (a.f1=bf1) and (a.f1=1)）是否满足，满足条件的记录，作为结果集的一行返回。如果语句中有 where 子句，需要先判断 where 部分满足条件后，再返回；
- 表 b 扫描完成后，对于没有被匹配的表 a 的行（在这个例子中就是 (1,1、(2,2) 这两行），把剩余字段补上 NULL，再放入结果集中。
Simple Nested Loop Join 的性能问题
BNL 算法的执行逻辑
- 首先，将驱动表的数据全部读入内存 join_buffer 中，这里 join_buffer 是无序数组；
- 然后，顺序遍历被驱动表的所有行，每一行数据都跟 join_buffer 中的数据进行匹配，匹配成功则作为结果集的一部分返回。
MySQL 中索引结构和 Buffer Pool 的相关知识点
- 在对被驱动表做全表扫描的时候，如果数据没有在 Buffer Pool 中，就需要等待这部分数据从磁盘读入；
从磁盘读入数据到内存中，会影响正常业务的 Buffer Pool 命中率，而且这个算法天然会对被驱动表的数据做多次访问，更容易将这些数据页放到 Buffer Pool 的头部。 - 即使被驱动表数据都在内存中，每次查找 “下一个记录的操作”，都是类似指针操作。而 join_buffer 中是数组，遍历的成本更低。
distinct 和 group by 的性能
select a from t group by a order by null;
select distinct a from t;
select a,count(*) from t group by a order by null;
两条语句的执行流程
- 创建一个临时表，临时表又一个字段 a，并且在这个字段 a 上创建一个唯一索引；
- 遍历表 t，依次取数据插入临时表中：
a. 如果发现唯一键冲突，就跳过；
b. 否则插入成功； - 遍历完成后，将临时表做诶结果集返回给客户端。
备库自增主键问题
即使两个 INSERT 语句在主备库的执行顺序不同，自增主键字段的值也不会不一致。
末了
重新总结了一下文中提到的内容：回顾了所有的问题。
