自增id出现间隙不是故障，而是innodb在并发写入时为平衡性能与一致性主动采用预分配策略所致；根本原因是innodb_autoinc_lock_mode=1默认模式下，简单insert预取id段、mixed-mode插入（如on duplicate key update）强制锁表预占批量id、事务回滚不回收已分配值，导致id不可逆跳号。
自增ID出现间隙不是故障，是InnoDB在并发写入时主动做的性能-一致性权衡。 你看到的“跳号”，基本都来自 innodb_autoinc_lock_mode 的预分配行为，而不是误操作或bug。
innodb_autoinc_lock_mode=1 是间隙最常见来源
MySQL 5.7+ 默认值就是 1（interleaved 模式），它对不同 INSERT 类型区别对待：
- 简单 INSERT（如
INSERT INTO t (a) VALUES (1)）不加表级AUTO_INC锁，但会从缓存池里“预取”一段 ID（比如一次拿 10 个）；哪怕只插 1 行，剩下 9 个就永远空着 - mixed-mode 插入（含
ON DUPLICATE KEY UPDATE、INSERT SELECT、REPLACE INTO或 ORM 的bulkCreate({ignoreDuplicates: true})）必须提前预估行数，锁表分配 ID——哪怕最终只成功 2 行，预占的 50 个 ID 全丢 - 事务回滚时，已分配但未提交的 ID 不回收，直接作废
ON DUPLICATE KEY UPDATE 为什么特别“费 ID”
这条语句被 InnoDB 归类为 mixed-mode，执行前就得把整批可能插入的 ID 全占住。例如：
INSERT INTO t (id, name) VALUES (NULL, 'a'), (NULL, 'b') ON DUPLICATE KEY UPDATE name = VALUES(name);
即使 name 是唯一索引且两条都命中冲突、实际没插入新行，InnoDB 仍会预分配 ID 段（比如 1001–1010），全部浪费。
- Sequelize、MyBatis 等 ORM 封装的“去重批量插入”，底层往往就是这种语法
- 哪怕没有真实冲突，只要语句结构匹配 mixed-mode 规则，预分配就发生
- 用
INSERT IGNORE替代可避免部分预占（它属于 simple insert），但无法更新已有行
删除和手动插入也会制造不可逆间隙
这两类是“非并发相关”但同样不可忽视的间隙来源：
- DELETE 任意一行（如
DELETE FROM t WHERE id = 5），该 ID 永远消失，后续 INSERT 不会复用 - 显式指定
INSERT INTO t (id, ...) VALUES (100, ...)，若 100 已存在会报错；若不存在，它会“卡位”，导致之后的自增从 101 继续，中间若有空档就彻底断开 - 主从复制中，从库执行
INSERT ... SELECT时若 binlog_format = STATEMENT，可能因执行顺序不同生成重复或跳跃 ID
真正难处理的不是“为什么有间隙”，而是“间隙不可预测且无法事后填补”——AUTO_INCREMENT 值一旦被预占或删除，就再也不会回到可用池里。业务若强依赖连续 ID（比如用作对外展示编号），得从设计层绕过自增，改用应用层生成（如雪花 ID）或带业务含义的编码方案。
