第 4 篇提过自增主键，让主键索引尽量递增顺序插入，避免页分裂，索引更紧凑。
不能保证连续递增。什么情况出现 “空洞”？主键冲突、回滚、批量申请。
id 自增主键、c 唯一索引
一、自增值保存在哪儿？
insert into t values(null, 1, 1); show create table
AUTO_INCREMENT=2，下一次插入，生成 id=2。
表的结构定义存放在后缀名为.frm 的文件中，不会保存自增值。
MyISAM 保存数据文件；InnoDB 自增值保存内存里（MySQL 8.0记录redo log 中），重启恢复为重启前值
MySQL 5.7 前，没持久化。最大值 max(id)=10，AUTO_INCREMENT=11。删除 id=10 的行，AUTO_INCREMENT 还是 11。重启AUTO_INCREMENT 0。重启修改AUTO_INCREMENT。
二、自增值修改机制
id 被定义为 AUTO_INCREMENT，
1. 插入时 id 字段指定 0、null 或未指定值，AUTO_INCREMENT 填自增字段；
2. id 指定具体值，用指定值。
插入 X，自增值 Y。
1. X（2）<Y（3），自增值不变；
2. 如果 （2）X≥Y（1），前自增值改为新自增值X
新自增值生成算法是：自增的初始值auto_increment_offset(默认1)开始， 步长auto_increment_increment (默认1)为，持续叠加，第一个大于 X 值，作为新的自增值。
ps：用的不全是默认值。如双 M 主备结构里双写，auto_increment_increment=2，让自增 id 都是奇数，另一都是偶数，避免主键冲突。
插入的值 >= 当前自增值，新自增值就是“准备插入的值 +1”；否则不变。
两个参数都设置为 1 的时候，自增主键 id 却不能保证是连续的，这是什么原因呢？
三、自增值的修改时机
3.1主键冲突
已经有了 (1,1,1) insert into t values(null, 1, 1);
1. 写入一行(0,1,1);
2. 没有指定自增 id 的值，t 当前的自增值 2；
3. 改成(2,1,1)；自增值改成 3
4. 已经存在 c=1 的记录，所以报 Duplicate key error，语句返回。
没有插入成功，自增值不再改回去。不连续。
3.2回滚也会产生类似现象
自增值不能回退：提升性能
两个并行事务，加锁顺序申请。
1. A 申请到了 id=2， B id=3， t 的自增值是 4，
2. B 提交， A 出现唯一键冲突。
3. 如允许A 自增 id 回退， t 改回 2，问题：id=3 再申请到 id=3（已有）“主键冲突”
解决主键冲突方法（ 都导致性能问题，放弃）：
1. 申请前判断，存在跳过。成本高。因为，本来申请 id 是一个很快的操作，现在还要再去主键索引树上判断 id 是否存在。
2. 锁范围扩大，事务完提交，下一个再申请自增 id。粒度太大，并发能力下降。
四、自增锁的优化
4.1 innodb_autoinc_lock_mode控制锁粒度
0：5.0 策略，语句结束释放；
1 (默认)：普通 insert ，自增锁申请后释放；
insert …select 批量插入，语句结束释放；
2 ：申请后释放锁
ps：5.0 版本，自增锁，语句级别。申请表自增锁，结束释放，影响并发度。
4.1 为什么默认、insert … select用语句级锁？默认值不是 2？
数据的一致性
t1 插入4 行，创建相同结构表 t2，同时向 t2 插入。
如果 B 申请自增值后马上释放自增锁，情况：
B 先插入了两个记录，(1,1,1)、(2,2,2)；
A 来申请自增 id 得到 id=3，插入了（3,5,5)；
B 插入两条记录 (4,3,3)、 (5,4,4)。
B 本身就没要求 t2 跟A 相同。如果binlog_format=statement，binlog 里id 连续。数据不一致。
问题原因：B 的 insert 语句，生成id 不连续。statement 格式的 binlog 串行执行，执行不出来。
解决两种思路：
1. 批量插入数据语句，固定生成连续 id 值。语句结束释放
2. binlog如实记录进来，备库执行，不依赖于自增主键生成。innodb_autoinc_lock_mode = 2，binlog_format = row。生产上，尤其insert …select 批量插入数据时，提升并发性，不会数据一致性。
批量插入数据包含： insert …select、replace … select 和 load data
普通 insert 多个 value 情况，innodb_autoinc_lock_mode 设置 1，精确计算出要多少个 id 的，一次性申请，释放。
4.2 批量申请自增 id 的策略（ 不连续第三种原因 ）：
1. 第一次申请自增 id，会分配 1 个；
2. 第二次申请自增 id，会分配 2 个；
3. 第三次申请自增 id，会分配 4 个；依此类推，上一次的两倍
实际上t2 中插入 4 行，分三次，1，第二次id=2 和 id=3， 第三次id=4 到 id=7。
id=5 到 id=7 浪费掉
再执行 insert into t2 values(null, 5,5)，实际上插入的数据就是（8,5,5)。
小结
自增值存储。
MyISAM 里，被写数据文件上。 InnoDB 中，记录内存的。重启前后不变。
自增值改变时机，回滚不能回收自增 id。
innodb_autoinc_lock_mode，控制自增值申请锁范围。并发性能考虑，设置为 2，binlog_format =row。
思考题
最后例子，执行 insert into t2(c,d) select c,d from t; 隔离级别是可重复读（repeatable
read），binlog_format=statement。所有记录和间隙加锁。为什么这么做？
如果 insert …select 有其他线程操作原表，不会导致逻辑错误。如不加锁，就是快照读(执行期间，一致性视图是不会修改)。
不对t表所有记录和间隙加锁，，可重复读，其他提交t2看不到。但binlog=statement，备库或基于binlog恢复临时库t2看到，不一致。
评论1
自增id和写binlog是有先后顺序的。binlog=statement，A获取id=1，B获取id=2，B提交，写binlog，再A写binlog。
如果binlog重放，不会出现不一致，B的id为1，A的id为2的情况
因为binlog记录自增值语句前，前面多一句，指定“自增ID值多少”，对应主库自增值
