MySQL自增主键不连续不是故障，而是InnoDB为保障并发安全与写入性能所做的主动设计；事务回滚、唯一键冲突、批量插入及配置参数均会导致跳号，属预期行为而非缺陷。
MySQL自增主键不连续不是故障，是InnoDB为并发安全和写入性能做的主动设计——只要没手动改过auto_increment_offset或auto_increment_increment，所有“跳号”都符合预期。
INSERT IGNORE 或 ON DUPLICATE KEY UPDATE 为什么会跳 ID
这类语句在执行早期就向引擎申请了自增值，早于唯一约束检查。哪怕整条语句最终什么都没插入，ID 也已被消耗且不可回收。
-
Duplicate entry 'xxx' for key 'uk_email'报错时，ID 已从 100 升到 101，下一条成功插入就是 101 -
INSERT IGNORE INTO users (email) VALUES ('a@b.com')和INSERT INTO users (email) VALUES ('a@b.com') ON DUPLICATE KEY UPDATE updated_at = NOW()行为一致：都跳号 - MyISAM 和 InnoDB 都跳，只是 InnoDB 在批量场景（如
INSERT ... SELECT）下因innodb_autoinc_lock_mode = 1预留更多，跳得更猛
事务回滚后 AUTO_INCREMENT 为什么不回退
回滚不归还 ID 是为了规避并发冲突。如果多个事务同时竞争下一个 ID，又允许回退，就得加全局锁或反复查表，性能会断崖式下跌。
- 执行
BEGIN; INSERT INTO t (name) VALUES ('x'); ROLLBACK;后，AUTO_INCREMENT值已+1 - 这个行为与是否显式开启事务无关：单条 INSERT 失败（如触发器报错）同样跳号
- MySQL 8.0+ 将自增值持久化进 redo log，重启不会重算
MAX(id)+1；5.7 及以前重启后可能“突变”，但本质仍是设计使然
DELETE 和 TRUNCATE 对自增值的影响完全不同
DELETE FROM t 不影响计数器，TRUNCATE TABLE t 则会重置它——但后者是 DDL，会重建表，有锁表、清元数据、破坏外键依赖等副作用，不能当“填洞”工具用。
- 删掉
id = 5的行，再插入新记录，ID 不会变成 5，而是继续按当前计数器走（比如当前是 10，新行就是 10） -
TRUNCATE后AUTO_INCREMENT回到 1，但该操作不可回滚、会重置所有自增列、且在有外键引用时直接报错 - 试图用
ALTER TABLE t AUTO_INCREMENT = N“修复”连续性？必须满足N > MAX(id)，否则 MySQL 静默忽略，不报错也不生效
哪些操作真正不会触发自增分配
只有明确绕过自增逻辑的操作才不跳号。但它们往往带来其他代价，比如一致性风险或性能下降。
- 显式指定主键值：
INSERT INTO t (id, name) VALUES (100, 'x')→ 不跳号，但 1–99 永久废弃 - 用
SELECT ... FOR UPDATE先查再插 → 可避免跳号，但多一次网络往返 + 行锁开销，高并发下易成瓶颈 - 改用
UUID或雪花 ID → 解决跳号，但失去整型主键的排序、索引压缩、JOIN 效率优势
真正危险的不是 ID 跳号，而是把 ID 当作序号、分页依据或硬编码范围来用。空洞本身无害，强行“修复”却可能引发主从延迟、外键断裂、应用缓存错乱——这些才是线上事故的常见源头。
