mysql自增主键在事务回滚后必然跳号，因id在insert时分配且不可回收，这是innodb为并发性能做的主动设计；alter table auto_increment=n仅重设下一起始值，不填补空缺，且需n大于当前max(id)。
MySQL自增主键在事务回滚后必然丢失连续性，无法“保证”，只能接受或绕过。 这不是缺陷，而是InnoDB为保障并发性能和原子性做的主动取舍。试图“修复”它，往往比问题本身更危险。
事务回滚为什么一定导致ID跳号
回滚时，自增ID早已被分配出去——这个动作发生在INSERT语句执行阶段，而非COMMIT阶段。一旦分配，即使事务失败，ID也不会回收。
- 示例：事务中执行
INSERT INTO t(name) VALUES('a')，拿到ID=100；随后ROLLBACK；下一条无事务的INSERT将得到ID=101，ID=100永久空缺 - 根本原因：回收ID需加全局锁、校验所有未提交事务、重排计数器——这会严重拖慢高并发写入
- MySQL 8.0+虽将AUTO_INCREMENT值持久化到redo log，但依然不改变“分配即消耗”的语义
ALTER TABLE AUTO_INCREMENT = N 能否补救
不能“补救空缺”，只能重设下一次插入的起点。且必须严格满足条件，否则直接报错。
-
ALTER TABLE t AUTO_INCREMENT = 100只影响下一条无显式ID的插入，新ID就是100，不是99或101 - N必须大于当前
MAX(id)，否则执行时报ERROR 1062 - 该语句对InnoDB表加写锁，大表执行期间阻塞所有DML；MyISAM表重启后可能失效
- 若表有外键引用，改了
AUTO_INCREMENT起点不影响已有数据，但若你后续手动UPDATE旧ID，必须同步更新关联表——极易引发级联错误
主从环境下的连续性陷阱
主从之间AUTO_INCREMENT值不同步是常态，盲目对齐反而引发冲突。
- 主库执行
SELECT MAX(id)得12344，ALTER TABLE ... AUTO_INCREMENT = 12345；但从库可能因复制延迟、auto_increment_offset配置差异，实际AUTO_INCREMENT值是12350甚至更高 - 导入dump文件时，若跳过了
AUTO_INCREMENT=那行（比如用了--skip-extended-insert），从库就彻底失去起点信息 - 真正要防的不是“不连续”，而是主从ID冲突导致的
Duplicate entry错误——这会让复制中断
连续性只是视觉幻觉。业务逻辑里硬编码“ID必须连续”等于给自己埋雷：一旦遇到事务回滚、批量插入失败、主从切换或服务器重启，空洞就会暴露。真正该关注的是ID唯一性、不可预测性、以及是否被用作对外展示（如订单号）——后者应完全脱离AUTO_INCREMENT，改用业务生成策略。
