MySQL 回滚或插入失败后，AUTO_INCREMENT 为什么出现缺口

第一次插入拿到 ID 1，重复用户名导致下一次插入失败，再插入另一名用户时却拿到 3。这个缺口不能单独证明丢了一条记录：InnoDB 分配的自增值不会随着插入失败或事务回滚恢复成未使用状态。

自增 ID 不是已提交行数

事务可能先取得一个自增值，随后才遇到唯一约束等错误。另一个事务也可能已经取得后面的值；回滚当前数据时，不能把所有事务共用的计数器一起倒退。

按 MySQL 8.4 InnoDB 的规则，三种自增锁模式都可能在回滚后留下已分配值的缺口。“consecutive” 锁模式里的语句级连续性，也不保证跨事务、跨失败请求的 ID 永远连续。

先在应用实际使用的数据库中核对版本与表结构，users 是示例表名：

SELECT VERSION();
SHOW CREATE TABLE users;

检查存储引擎、自增列和其他唯一约束，并对照原始失败日志。不能把 SQLite 的自增规则、其他引擎或不同数据库的序列规则直接代入。

需要区分语句失败和事务结束。InnoDB 中，普通重复键错误通常回滚失败的语句；死锁则会回滚整笔事务，锁等待超时还取决于配置。

如果先成功插入 A，再因插入 B 报错，最后仍执行 COMMIT，不能只凭 B 的错误认定 A 被撤销。要核对同一连接的 SQL 顺序，以及应用是否明确执行了回滚；原子业务应由既有事务管理流程在失败时结束整笔事务。

反过来，已经确认 ROLLBACK 成功、业务数据没有提交，自增缺口仍可能保留。不要用“下一个 ID 是否还连续”代替业务记录的提交验收。事务里含普通 DDL 时，还要检查结构操作的隐式提交。

不要自动把 AUTO_INCREMENT 调小、重写现有主键或让下一条记录复用某个缺号。这会影响并发写入、外键、缓存和外部已记录的对象身份；缺口本身不需要这样的修复。

业务需要连续展示编号时，应使用独立的业务编号规则，明确分配时间、并发与失败后的处理，不能把数据库主键当成连续流水账。取消、删除和失败记录如何保留，也应由业务规则决定。

MySQL 8.4 的计数器具有持久化机制，正常重启不是补回缺号的方法；意外退出与 redo log 刷盘又有边界，不能承诺所有版本和崩溃情况下已分配值永不复用。

调查时保存错误、SQL 顺序和相关记录身份，分别验收失败业务是否按约定回滚、成功业务是否确实提交。只有出现不符合事务或唯一约束的实际结果，才继续按那个结果排错；单独的编号跳跃不应触发数据重建。