当前位置：首页 > 文章列表 > 数据库 > MySQL > MySQL 事务回滚后自增主键为什么不连续：AUTO_INCREMENT 与业务编号的边界

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

来源：17golang原创 2026-08-25 19:54:37 0浏览收藏

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

要点速览

事务回滚不会把已经分配的 AUTO_INCREMENT 值可靠地归还给下一次 INSERT。
主键的核心约束是唯一和可引用，不是无缺口递增；删除、并发和批量插入也会制造空洞。
业务编号不要直接复用自增主键，应该单独设计生成时机、唯一约束和失败重试策略。
验收时同时看事务日志、提交结果、主键值和业务编号，不能只凭“数字是否连续”下结论。

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

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

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

MySQL AUTO_INCREMENT 分配 101 后事务 ROLLBACK，下一次提交得到 102 的主键空洞证据图

用最小实验复现一次回滚

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

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 为什么不适合承担连续编号

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

现象	主键可能发生什么	业务上应该关注什么
INSERT 后回滚	已分配的值留下空洞	回滚原因和重试率
删除已提交行	被删除的值不会自动补回	审计记录和外键关系
并发插入	提交顺序可能不同于编号顺序	创建时间与状态流转
批量插入失败	可能消耗一段编号范围	失败批次与幂等键

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

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

订单表可以同时保留数据库主键 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;

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