mysql自增id跳号是innodb为保证唯一性、并发安全和事务语义的正常设计，不可逆且无需修复；事务回滚、insert ignore、批量插入等均会导致id预分配后不回收，强行补号或alter table重置易引发主键冲突。
MySQL自增ID跳号不是故障，是InnoDB在保证唯一性、并发安全和事务语义前提下做出的设计取舍。跳号本身不可逆，也不该修复——强行“补号”反而容易引发主键冲突。
事务回滚后ID不回收是正常行为
只要语句触发了自增列生成（比如插入时写 NULL 或省略 id 字段），InnoDB 就会在执行阶段立即预分配一个 ID。这个动作发生在事务提交之前，所以即使你随后执行 ROLLBACK，ID 也已经消耗掉了。
-
INSERT INTO t (name) VALUES ('x');→ 分配 ID=100，再ROLLBACK→ 下次插入从 101 开始 -
INSERT IGNORE INTO t (name) VALUES ('duplicate');→ 唯一键冲突导致行未写入，但 ID=101 已被占用 -
INSERT INTO t SELECT NULL, c FROM src LIMIT 5;→ 可能一次性预占 1→2→4 个 ID，实际只用 3 个，剩下 2 个永久丢失
批量导入或定时任务放大跳号幅度
Navicat 定时任务、LOAD DATA INFILE、INSERT SELECT 这类操作默认触发“幂次预分配”：第一次申请 1 个，第二次 2 个，第三次 4 个……越往后预留越多。尤其当 innodb_autoinc_lock_mode = 2（MySQL 8.0+ 默认）时，这种行为更明显。
- 一次导入 10 行，可能实际消耗 16 个 ID，中间空出 6 个
- 定时任务配置了“清空表再导入”，每次都会执行
TRUNCATE TABLE→AUTO_INCREMENT重置为 1，若目标表非空，下次插入直接报错Duplicate entry '1' for key 'PRIMARY' - Navicat 结构同步时若勾选了“导出 AUTO_INCREMENT 值”，会把源库的
AUTO_INCREMENT=892直接写进目标表 DDL，完全无视目标表真实最大 ID
ALTER TABLE AUTO_INCREMENT = N 是高危操作
这条语句不能“修复”跳号，只会制造新的风险。MySQL 不校验你设的值是否大于当前表中最大 id，只做向上取整；设小了会被静默修正，设大了则立刻生效，且不受并发保护。
- 执行前必须先查：
SELECT IFNULL(MAX(id), 0) + 1 FROM t - 设完不等于立刻生效：已有缓存或预分配段仍按旧逻辑走，新值只对下一次真正需要自增的 INSERT 生效
- 高并发写入期间执行该语句，可能被其他会话的预分配行为覆盖，结果不可预测
- 千万别用
ALTER TABLE t AUTO_INCREMENT = 1清零，除非确认表为空
真正要盯住的是 binlog 和 lock_mode 组合
跳号本身无害，但搭配错误配置会引发主从不一致——这才是线上事故的高发区。例如：
-
binlog_format = STATEMENT+innodb_autoinc_lock_mode = 2→ 主库分配 ID 的顺序与从库重放时不一致，导致从库主键冲突或数据错位 - 主从切换后，若启用了
auto_increment_offset和auto_increment_increment，跳号会更剧烈且难以追踪 -
SHOW CREATE TABLE显示的AUTO_INCREMENT=xxx在重启后完全不可信，它只是内存快照，不是持久化状态
最常被忽略的一点：跳号不是问题，误以为它是问题并动手“修复”，才是真问题。业务上若强依赖连续编号（如发票号、合同号），应放弃自增，改用应用层可控的序列服务或 UUID+时间戳组合。
