MySQL 事务回滚后自增主键为什么不连续：AUTO_INCREMENT 与业务编号的边界

订单表里看到主键从 100 跳到 102，通常不是 MySQL 把一行数据“吃掉”了，而是某次 INSERT 已经拿到了自增值，后续事务又回滚了。InnoDB 的 AUTO_INCREMENT 负责分配唯一标识，不负责保证提交记录没有空洞；订单号、发票号这类需要连续或可读的编号，应当由独立的业务规则处理。

先把“空洞”与“数据丢失”分开

假设一张实验表当前最大主键是 100。事务 A 执行 INSERT，拿到 101，但在提交前遇到校验失败并执行 ROLLBACK；之后事务 B 再插入一行，得到 102。查询结果里没有 101，这是自增分配和事务提交属于两条不同的逻辑线，不等于事务 B 读到了错误数据。

真正需要报警的是这些现象：同一个主键出现两行、业务表的外键指向不存在的记录、提交成功但业务编号重复，或者回滚比例突然升高。单独看到编号不连续，证据还不够。

用最小实验复现一次回滚

不要拿线上订单表做验证，先在测试库建立一张只包含主键和描述字段的表：

CREATE TABLE order_no_demo (
  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  note VARCHAR(64) NOT NULL,
  PRIMARY KEY (id)
) ENGINE=InnoDB;

START TRANSACTION;
INSERT INTO order_no_demo (note) VALUES ('will rollback');
ROLLBACK;

INSERT INTO order_no_demo (note) VALUES ('will commit');
SELECT id, note FROM order_no_demo;

在常见的 InnoDB 配置下，最后一行可能显示为 102，而不是 101。这里的“可能”很重要：自增值分配还会受并发插入、批量 INSERT、服务器重启和存储引擎实现影响。实验的目的是理解边界，不是把某个数字写成业务保证。

AUTO_INCREMENT 为什么不适合承担连续编号

自增列的工作重点是快速产生候选唯一值。它不等到事务最终提交才决定编号，因为并发事务需要在插入阶段就拿到互不冲突的值；如果每次回滚都强行回收，还会增加并发协调和复用风险。

因此，主键适合做内部引用、索引连接和稳定身份；它不应该被当作“当天第几笔订单”或“发票序号”的天然替代品。

业务编号要和主键分层设计

订单表可以同时保留数据库主键 id 和面向业务的 order_code。前者追求唯一、索引友好、外键稳定；后者根据业务要求选择日期前缀、租户编码、号段、流水或外部单号，并单独加唯一约束。

CREATE TABLE orders (
  id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT,
  order_code VARCHAR(32) NOT NULL,
  status VARCHAR(16) NOT NULL,
  created_at DATETIME NOT NULL,
  PRIMARY KEY (id),
  UNIQUE KEY uk_orders_order_code (order_code)
) ENGINE=InnoDB;

如果业务要求“失败订单不占号”，编号生成就应放在明确的业务状态边界之后；如果要求高并发下先拿号再创建订单，则必须接受取消、超时和重试产生的空号，并在规则里说明“连续”到底指什么时间范围和什么状态集合。

并发场景里不要用主键顺序推断业务时间

事务 A 先拿到 103，但因为等待外部校验，事务 B 先提交了 104。此时按 id 排序并不能还原真实创建顺序。需要时间线时，使用明确的 created_at、提交事件或业务流水记录，并规定时区和精度。

同理，分页也不要把“主键连续”当成没有漏数据的证明。基于 id > last_id 的游标分页只要求主键可比较、稳定且有索引；它不要求中间每个整数都存在。

验收时看四组证据

1. 事务证据：记录 INSERT、COMMIT 或 ROLLBACK 的结果，不只截取最终 SELECT。
2. 约束证据：检查主键唯一性、业务编号唯一索引和外键一致性。
3. 时间证据：用 created_at 或事件日志判断顺序，不用自增值代替时间。
4. 恢复证据：对失败重试使用幂等键，确认重复请求不会创建两个业务订单。

如果团队确实需要无空号票据或发票编号，应把它当作独立的号段/序列问题评审，写清并发、回滚、补号、作废和审计要求。直接把 AUTO_INCREMENT 改成“必须连续”，往往只会把数据库主键和业务规则绑死。

相关问题

回滚后能不能手动把 AUTO_INCREMENT 改回去？

不建议把回收空号当成常规修复。并发插入、复制和已有引用都会让手动调整产生误判；除非是经过评审的测试数据清理，否则保留空洞更安全。

删除订单后主键不连续正常吗？

正常。删除改变的是可见记录，不会要求数据库重新编号；重新编号还可能破坏外键、日志和外部引用。

订单号必须连续时应该怎么做？

先定义连续范围和作废规则，再选择独立号段或序列服务，并用唯一约束、事务边界和审计记录保证可追踪，不要复用内部主键。

主键空洞会影响索引性能吗？

少量空洞通常不是性能问题。真正需要关注的是主键类型、写入热点、页分裂、索引大小和访问模式，不能仅凭数字间隔判断性能。

小结

MySQL 的自增主键解决的是唯一标识和并发插入，不承诺提交记录连续，更不等价于业务时间或订单流水。把回滚、删除、并发造成的空洞视为正常边界；把连续编号、可读编号和审计要求放到独立的 order_code 设计里，系统才更容易验收和回退。