SQL插入数据时如何保证主键ID连续？

MySQL 自增 ID 不连续这事儿，其实是设计故意为之，不是 bug。根本原因包括事务回滚、唯一键冲突、批量插入预分配等，都会预占 ID 且不可回收。所以业务层别指望它能连续，趁早放弃这个执念。

MySQL 自增 ID 的连续性？别想了，它从一开始就没打算给你保证。这纯粹是设计使然，不是 bug。如果你非要“保证连续”，那就得绕开 AUTO_INCREMENT 的默认行为，手动去补位。但代价呢？并发安全风险、锁表、外键断裂、应用层逻辑错乱——这些你都得掂量掂量。生产环境里，为了一个“看起来连续”的 ID 搞出大问题，实在不值得。

为什么 INSERT 后 ID 会跳号？

触发跳号的场景其实挺常见的，稍微一不留神就踩坑：

• INSERT IGNORE 或 INSERT ... ON DUPLICATE KEY UPDATE 失败时，AUTO_INCREMENT 计数器照样递增，不会因为你没插进去就退还 ID。
• 事务里先 INSERT 然后 ROLLBACK，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 连不连续，先保证不冲突、不丢数据，这才是正事。