自增ID为何跳号

自增 ID（如 MySQL 的 AUTO_INCREMENT）出现跳号（不连续）是非常常见的现象，通常并不是 bug，而是由数据库的设计机制或运行行为导致的。下面按常见原因系统说明：

一、事务回滚导致跳号（最常见）

BEGIN;
INSERT INTO t(id, name) VALUES (NULL, 'a'); -- 分配 id=10
ROLLBACK;

• 自增 ID 一旦分配就不会回收
• 回滚后，10 被“浪费”
• 下次插入从 11 开始

✅ 这是预期行为

二、插入失败（非回滚）

例如：

• 唯一键冲突
• 字段超长
• 类型错误

INSERT INTO t(id, name) VALUES (NULL, 'dup'); -- 冲突

• ID 已分配
• 插入失败
• ID 被跳过

三、批量插入只分配一次，但部分失败

INSERT INTO t(name) VALUES ('a'),('b'),('c');

• 分配 3 个 ID
• 若中间某条失败，可能跳过部分 ID

四、DELETE 删除数据不会回收 ID

DELETE FROM t WHERE id = 100;

• 100 被删
• 下一个 ID 依然是 101

❗ 自增 ID 只增不回收

五、MySQL 8.0 之前的“宕机跳号”

• MySQL 5.7 及之前：
  • AUTO_INCREMENT 只存在于内存
  • 宕机后重启可能重新计算
  • 导致大幅跳号（如 +1, +2, +N）

MySQL 8.0 已修复（持久化到 redo log）

六、显式插入 ID

INSERT INTO t(id, name) VALUES (1000, 'x');

• 自增计数器被推高
• 后续从 1001 开始

七、主从复制 / 集群环境

• 双主、MGR、分库分表
• 使用 auto_increment_increment / auto_increment_offset

实例1: 1,3,5,7
实例2: 2,4,6,8

• 看起来“跳号”其实是设计使然

八、TRUNCATE vs DELETE

TRUNCATE TABLE t;

• 重置自增计数器
• DELETE 不会

九、你“以为”跳号，其实没有

• 隐藏的：
  • 定时任务
  • 软删除
  • 测试数据
  • 内部表操作

十、是否需要解决？

✅ 一般不需要

• 自增 ID 只需：
  • 唯一
  • 趋势递增
• 不要求连续

❌ 不应依赖 ID 连续做业务判断

如果你想要“连续 ID”

可选方案：

• 使用业务编号（如订单号）
• 查询时 ROW_NUMBER()
• 单独维护计数表（有并发风险）

如果你愿意，可以告诉我：

• 用的什么数据库（MySQL / PostgreSQL / Oracle）
• 是否主从 / 集群
• 跳号幅度（偶尔 / 大量）

我可以更精确地判断原因。