mysql自增主键不连续是正常设计，因事务回滚、唯一键冲突、批量插入等均会预分配id且不可回收，业务层不应依赖其连续性。
MySQL 自增主键不连续是常态，不是 bug；强行“修复”连续性往往带来更大风险。真正该做的是理解它为何不连续，并在业务层规避对连续性的依赖。
事务回滚时自增值已分配，无法回收
这是最常被误判为“异常”的场景。InnoDB 的 AUTO_INCREMENT 值在语句执行初期就预分配，哪怕后续因唯一键冲突或 ROLLBACK 导致插入失败，该 ID 也不会退还。
- 执行
SET autocommit = 0; BEGIN; INSERT INTO t VALUES (NULL, 2, 2); ROLLBACK;后，SHOW CREATE TABLE t显示的AUTO_INCREMENT值已 +1 - 该行为与
innodb_autoinc_lock_mode设置无关——只要用了NULL或未指定主键值，就触发预分配 - 无法通过任何 SQL 撤销已跳过的 ID，也不建议用
ALTER TABLE ... AUTO_INCREMENT = N回拨（可能引发主键冲突）
批量插入（INSERT ... SELECT、REPLACE、LOAD DATA）会预占多段ID
当使用批量语句插入多行时，InnoDB 为避免锁竞争，会一次性申请比实际行数更多的自增值，造成明显断层。
- 例如：表当前
AUTO_INCREMENT = 100，执行INSERT INTO t SELECT NULL, c, d FROM src LIMIT 5，最终AUTO_INCREMENT可能变成 108 或更高 - 这种“预留膨胀”在
innodb_autoinc_lock_mode = 1（默认）下尤为明显；设为 2（交错模式）可缓解但不消除 - 若必须控制 ID 分配节奏，改用单条
INSERT循环（牺牲性能）或显式指定主键值（需业务层生成）
唯一键冲突也会消耗自增ID
很多人只注意事务回滚，却忽略唯一索引（UNIQUE KEY）冲突同样会触发 ID 预分配并丢弃。
- 建表含
UNIQUE KEY c(c)，已有(1,1,1)；再执行INSERT INTO t VALUES (NULL, 1, 2)→ 报错Duplicate entry '1' for key 'c'，但AUTO_INCREMENT已升至 2 - 下一条成功插入
INSERT INTO t VALUES (NULL, 2, 2)得到id=2，看似连续；但如果中间有其他失败，断层立刻出现 - 排查方法：检查错误日志中是否有
1062错误码，结合SHOW CREATE TABLE观察AUTO_INCREMENT是否异常跳变
真正难处理的不是“怎么让 ID 连续”，而是业务逻辑是否隐式依赖了连续性——比如用 ID 做分页游标、导出序号、或对外暴露为订单号。这些地方一旦写死，后续扩容、分库、归档都会踩坑。ID 只应作为内部标识，连续性交给业务字段（如 serial_no）或应用层序列器来保障。
