SQL插入数据时如何确保主键ID的连续性？

MySQL自增ID不连续是设计使然而非bug，根本原因包括事务回滚、唯一键冲突、批量插入预分配等均会预占ID且不可回收，业务层应避免依赖其连续性。

MySQL 本身不保证自增 ID 的连续性，这是设计使然，不是 bug。想“保证连续”，本质是绕过 AUTO_INCREMENT 的默认行为，用人工干预补位——但必须清楚代价：并发安全风险、锁表、外键断裂、应用层逻辑错乱。

为什么 INSERT 后 ID 会跳号？

常见触发场景包括：

• INSERT IGNORE 或 INSERT ... ON DUPLICATE KEY UPDATE 失败时，AUTO_INCREMENT 计数器仍递增
• 事务中 INSERT 后 ROLLBACK，ID 已被预占
• REPLACE INTO 先删后插，原 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
• 该语句对 InnoDB 表加写锁，大表慎用；MyISAM 表重启可能失效
• mysqldump 导出文件末尾自带 AUTO_INCREMENT=...，但若导入时跳过 DDL（如用了 --skip-extended-insert 或手动删了那行），就会丢失

想让新插入的 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 值，导入后立刻报错。连续性只是表象，冲突才是要命的问题。