join性能问题，distinct和group by性能，备库自增主键问题

前言

读书笔记 做一下小总结

---

left join的判断条件都在on里面和部分在where里面有什么区别吗？

当在where里面时，那就在结果中就会过滤掉没有匹配到的值。

如果是都在on里面的话那么即使没有匹配到，左边驱动表也会展示然后后面没有匹配到的字段显示为null。

这里有一个知识点就是在mysql中任何值和null做判断无论是否符合结果都是null，即便是null = null 的结果也是null。因此在where中做判断时，如果出现了null的判断就直接返回了null导致不会有这条数据。这就是为什么where判断之后，不满足的数据会直接不展示的原因。

left join的左边一定会是驱动表吗？

在添加了where语句之后，优化器会去分析，如果和join的效果一样，那么就会把left join变成 join。

join就不在有驱动表和被驱动表。

BNL和SNL算法都需要轮询N*M次，为什么BNL快？

这里可以再复习一下关于left join 的两种执行算法流程：BNL和Simple Nested Loop join（SNL）

BNL的执行流程，首先会把驱动表的数据全部放到join- buffer中（如果放不下就分批次），然后获取被驱动表中的数据遍历和join- buffer中对比。

对于Simple Nested Loop join的执行流程是获取驱动表中的一行数据，然后到被驱动表做全表扫描。被驱动表的数据放到buffer-pool中，可能会导致buffer-pool中的热点数据失效，因为join需要多次轮询，所以即便是3/8的方式也容易导致3中也被替换掉。
同时需要大量的从磁盘查询，所以会导致SNL查询效率很慢这个问题。

distinct和group的性能区别：

对于大多使用group by的场景 其实涉及到再where a count(*) 来计算一行出现了多少次。所以会慢一些。

但是如果没有这一步的各种统计计算的话。那么他们两个的执行流程是一样的：

通过创建一个临时表，然后在排序的字段上添加唯一索引，然后把数据放到临时表里，有冲突跳过，没有写入。所以性能也是一样的。

备库自增主键问题：

这个问题是，如果binlog的格式是statement，那么自增主键的获取和提交到binlog的顺序可能会不一致，为什么备库上没有出现id的顺序混乱？

因为在binlog中有一个set insert_ID 的值会根据主库上申请的顺序先申请的设置成1

后申请但是先提交了就设置成2。也就是写入的时候会在原来的基础上+2

那么即使提交的顺序不一样，也会保持一致。