AUTO_INCREMENT空洞不是故障，而是InnoDB为并发安全与性能做的主动设计；事务回滚或冲突失败均会预分配ID且不回收，MySQL 8.0+通过redo log持久化避免重启回溯，DELETE不填洞，显式指定ID、INSERT IGNORE等操作均会导致不可逆空洞。
AUTO_INCREMENT 出现空洞或跳号，不是故障，是 InnoDB 为并发安全和性能做的主动取舍。只要没手动干预或配置错，它就是按设计运行的。
为什么事务回滚后ID还是跳了？
InnoDB 在执行 INSERT 语句前就分配了自增值，哪怕整条语句因主键/唯一键冲突或显式 ROLLBACK 失败，这个 ID 也不会退还。
- 比如当前
AUTO_INCREMENT值是 100，执行INSERT INTO t VALUES (1, 'x')报错Duplicate entry '1'→ 自增计数器仍升到 101 - 下一条成功插入的记录 ID 就是 101，不是重试 100
- 这是为了防止多个事务同时竞争同一个 ID，避免锁等待——代价就是“跳号”
MySQL 8.0 重启后还跳号吗？
不会。MySQL 8.0+ 把 AUTO_INCREMENT 值持久化到了 redo log 和数据字典里，崩溃或重启后不会丢失、也不会重建为 MAX(id)+1。
- 5.7 及以前：重启后靠
SELECT MAX(id)+1重建，如果表里有手动插入的大 ID（如INSERT INTO t VALUES (10000, ...)），重启后可能从 10001 开始，看起来像“突变” - 8.0+：值始终延续，
SHOW CREATE TABLE显示的AUTO_INCREMENT=xxx是真实生效值 - 验证方式：
SELECT @@auto_increment_increment, @@auto_increment_offset;+SHOW CREATE TABLE t;
DELETE 后为什么没“填洞”？
DELETE 不会触发自增计数器倒退，也不会让后续插入复用被删掉的 ID。
- InnoDB 的
AUTO_INCREMENT计数器只增不减，和行是否存在无关 - 删除某行（如 ID=5）后，新插入仍按当前计数器走，比如现在是 10，下一条就是 10，不是 5
- 想“回收”空洞？别试。人工重排（导出再导入、变量赋值、触发器）会破坏外键、主从一致性、应用缓存，风险远高于空洞本身
哪些操作最常制造不可逆空洞？
这些操作会直接改写或绕过自增机制，留下长期空洞：
- 显式指定 ID：
INSERT INTO t (id, name) VALUES (100, 'x')→ 下一个自增从 101 起，1–99 彻底废弃 -
INSERT IGNORE或INSERT ... ON DUPLICATE KEY UPDATE遇到冲突时仍消耗 ID，但没插入数据 -
REPLACE INTO：先删后插，旧 ID 被释放，但新行用的是下一个自增 ID，不是原 ID - 迁移时没带
AUTO_INCREMENT值，或目标库innodb_autoinc_lock_mode=1导致批量预分配（如INSERT SELECT）
WHERE id BETWEEN x AND y，或前端展示“第 N 条”，或中间件靠 ID 连续性做分片路由。这些场景该换方案，而不是修空洞。 
