MySQL 自增 ID 不连续并非程序缺陷，而是有意为之的设计。其根本原因在于事务回滚、唯一键冲突、批量插入预分配等机制都会预先占用 ID 且无法回收。因此，业务层不应依赖 ID 的连续性，尽早放弃这一执念更为明智。
MySQL 自增 ID 的连续性？从一开始设计就没打算保障。这是固化设计，并非缺陷。若强行要求连续，就必须绕开 AUTO_INCREMENT 默认行为，手动补位。但代价包括并发安全风险、锁表、外键断裂、应用层逻辑错乱等，必须权衡。生产环境中，为了追求表面连续的 ID 而引发重大故障，实在得不偿失。
为什么 INSERT 后 ID 会跳号？
触发跳号的场景其实挺常见的，稍微一不留神便可能踩坑：
- 使用
INSERT IGNORE或INSERT ... ON DUPLICATE KEY UPDATE失败时，AUTO_INCREMENT计数器仍会递增，不会因插入失败而退还已占用的 ID。 - 事务中先
INSERT后ROLLBACK，ID 已被预占，回滚操作也不会回收该 ID。 REPLACE INTO操作先删除后插入，原 ID 释放但不会复用，新插入直接申请下一个 ID。- 显式指定 ID 插入（如
INSERT INTO t(id, name) VALUES(100, 'x')），后续自增起点会跳到max(id)+1，中间空缺永远无法填补。
ALTER TABLE AUTO_INCREMENT = N 真的能修复连续性吗？
这个操作只能设置下一条插入的起点，无法填补已有的空缺。关键规则务必牢记：
- N 必须严格大于当前
MAX(id)，否则下次不带显式 ID 的INSERT将报ERROR 1062主键冲突。 - 执行
ALTER TABLE t AUTO_INCREMENT = 1000后，下条记录 ID 为 1000，而非 1。切勿指望它能从 1 开始重排。 - 该语句对 InnoDB 表施加写锁，大表操作需格外谨慎；MyISAM 表重启后设置可能失效。
- mysqldump 导出文件末尾自带
AUTO_INCREMENT=...，但若导入时跳过 DDL（如使用--skip-extended-insert或手动删除该行），该设置将丢失，后续插入的 ID 可能从 1 开始，导致冲突。
如何让新插入的 ID 连续？最可行的实操路径
前提是：你接受“只保证新增连续”，不重排历史 ID。重排历史 ID 会破坏外键、业务关联、日志追踪，代价太大，基本不推荐。具体做法如下：
- 首先清理所有唯一约束冲突的脏数据，例如
INSERT IGNORE失败残留的中间状态，应果断删除。 - 查询当前最大 ID：
SELECT MAX(id) FROM t - 将自增起点设为
MAX(id) + 1：ALTER TABLE t AUTO_INCREMENT = 12345（假设 MAX 为 12344） - 后续仅使用不带 ID 的
INSERT INTO t(name) VALUES('x')，新 ID 将从 12345 开始连续递增。
注意：如果表存在外键引用，且你修改了 ID 值，则必须同步更新关联表——这几乎必然引发级联风险，生产环境强烈不建议执行。确需修改，务必先在测试环境充分验证。
易被忽略的陷阱
主从架构下，AUTO_INCREMENT 值不同步是一个常见陷阱。若 auto_increment_offset 与 auto_increment_increment 配置不一致，主从 ID 可能发生冲突。迁移数据时，仅查询主库 MAX(id) 而未检查从库的 AUTO_INCREMENT 值，导入后立即报错。连续性只是表象，冲突才是致命问题。因此，不必纠结 ID 是否连续，优先确保不冲突、不丢失数据，这才是关键。
