mysql重启后innodb的auto_increment“跳变”是因为其值仅存内存，重启后执行select max(id)+1重建；若现存最大id为14则从15开始，哪怕曾分配过100，而myisam因持久化至.myi文件故不丢失。
MySQL重启后InnoDB的AUTO_INCREMENT为什么会“跳变”？
因为InnoDB只在内存中维护当前最大自增值，服务重启后会执行SELECT MAX(id) FROM table重新推算——如果表里现存最大ID是14，下一条就从15开始，哪怕之前分配过100。这和MyISAM完全不是一回事。
常见错误现象：SHOW CREATE TABLE显示AUTO_INCREMENT=100，但重启后插入新行却得到ID=15；监控发现ID“断崖式回退”，误以为数据被清空或配置出错。
关键细节：
- 该行为与
innodb_autoinc_lock_mode无关，是引擎底层设计决定的 - 即使表为空（
MAX(id)为NULL），重启后也会从1开始，而非保留之前的值 -
TRUNCATE TABLE会重置内存值并清空数据文件，但DELETE FROM不会影响下一次分配起点
MyISAM的AUTO_INCREMENT为何重启不丢？
MyISAM把当前最大ID持久化写入.MYI索引文件末尾，每次INSERT都读取、+1、再写回。所以删掉几条记录、甚至整个服务重启，只要没用TRUNCATE或手动修改.MYI，下一条ID一定是原最大值+1。
使用场景：日志归档表、只增不删的埋点表，依赖ID单调递增且不希望重启后“倒流”。
但要注意：
- 崩溃未正常关闭时，.MYI可能损坏，导致
MAX(id)丢失，需REPAIR TABLE修复 - 并发INSERT期间若发生中断，可能漏记一次+1，造成ID重复（虽概率极低）
- 无法保证全局唯一——跨表、跨库、主从不同步时都可能冲突
InnoDB中INSERT ... SELECT或事务回滚如何导致ID“空洞”？
InnoDB在语句执行阶段就预分配自增值，哪怕事务最终回滚，这个ID也作废不复用。比如事务A申请到ID=100并插入，事务B紧接着拿到101并提交，A随后回滚——100永远空缺，下一个新插入仍是102。
更隐蔽的是INSERT INTO t SELECT ...这类语句：它会在事务开始时批量预占一段ID（数量取决于估算行数），一旦事务中断或回滚，整段都浪费。
性能影响明显：
- 高频率小事务+回滚的业务（如库存预占失败场景），ID空洞率可达30%以上
- 主从复制用STATEMENT格式时，从库执行
INSERT ... SELECT可能因估算偏差分配不同ID段，引发主从不一致 -
INSERT IGNORE或ON DUPLICATE KEY UPDATE仍会触发自增分配，哪怕最终没插入新行
为什么别轻易调innodb_autoinc_lock_mode=2？
设成2（交错模式）确实能消除自增锁争用，让并发INSERT不排队，但代价是ID完全不可预测：同一事务内多条INSERT可能穿插分配，主从复制下STATEMENT格式会因执行顺序差异导致从库ID与主库不一致，最终丢数据。
生产环境真正需要的不是“连续”，而是“可预期”。如果你的业务逻辑真强依赖ID连续性（比如用ID做分页游标或导出序号），应该换思路：
- 用
UUID或Snowflake生成业务ID，把AUTO_INCREMENT仅当内部引用键 - 对关键表启用
innodb_autoinc_persist=ON（MySQL 8.0.30+），让自增值写入系统表空间持久化 - 避免在事务中混用
INSERT ... SELECT和高回滚率操作
最常被忽略的一点：InnoDB的“不连续”多数不是bug，而是事务原子性的必然代价——宁可空几个ID，也不能让两条UPDATE一半成功一半失败。
