mysql自增主键跳号是innodb_autoinc_lock_mode设计取舍所致，非bug；默认模式1下批量插入预分配且不回收、事务回滚不释放、主从复制配置不当均会导致跳号。
为什么 MySQL 的自增主键会跳号？
根本原因不是 bug，而是 innodb_autoinc_lock_mode 的设计取舍——它在并发插入、批量插入和复制安全之间做平衡。默认值 1（连续锁模式）下，INSERT ... SELECT、REPLACE INTO、LOAD DATA 等语句会预分配一大段自增值，哪怕中间有事务回滚，这部分 ID 也不会回收。
常见现象包括：
- 执行一次
INSERT INTO t SELECT ...后，自增 ID 突然从 100 跳到 2000+ - 事务 A 插入后未提交，事务 B 插入成功并提交，A 回滚，但 B 的 ID 已占用，A 占用的 ID 不归还
- 主从复制中出现不一致（尤其
STATEMENT格式 +auto_increment_offset配置不当）
三种 innodb_autoinc_lock_mode 值怎么选？
该参数控制 InnoDB 如何为自增列分配值，取值范围是 0、1、2，直接影响锁行为和 ID 连续性：
-
0（传统锁模式）：所有 INSERT 类语句都用表级AUTO-INC锁，严格保证连续，但并发极低，已不推荐 -
1（默认，连续锁模式）：简单 INSERT（如INSERT INTO t VALUES ()）用轻量互斥量，不锁表；批量插入（含INSERT ... SELECT）仍用表级锁并预分配，兼顾性能与复制安全 -
2（交错锁模式）：所有 INSERT 都不加表级锁，ID 分配完全交错，性能最高，但要求 binlog 必须为ROW格式，否则主从可能不一致
生产环境若用 STATEMENT 或混合 binlog 格式，不能设为 2；若已切到 ROW，且能接受 ID 不连续，2 是更现代的选择。
如何复现和验证当前锁模式的影响？
用最小可复现场景观察 ID 分配行为：
CREATE TABLE t (id INT PRIMARY KEY AUTO_INCREMENT, v VARCHAR(10)); SET innodb_autoinc_lock_mode = 1; -- 或 0 / 2 -- 在会话 A 中： START TRANSACTION; INSERT INTO t VALUES (),(),(); -- 分配 id=1,2,3 -- 不提交，保持事务打开 -- 在会话 B 中： INSERT INTO t VALUES (); -- 得到 id=4（mode=1 下） -- 若 mode=2，B 可能拿到 id=5 或更高（取决于内部分配器状态）
关键验证点：
- 查当前值：
SELECT @@innodb_autoinc_lock_mode; - 看实际分配：
SHOW CREATE TABLE t;中的AUTO_INCREMENT值只是“下一个待用值”，不代表已用尽 - 检查 binlog 格式：
SELECT @@binlog_format;，必须为ROW才能放心用 mode=2
想“修复”跳号，但要注意这些现实约束
自增 ID 不连续本身不影响功能，MySQL 官方明确将其视为正常行为。强行追求连续会付出明显代价：
- 设
innodb_autoinc_lock_mode = 0会导致高并发插入严重排队，TPS 断崖下跌 - 手动
ALTER TABLE ... AUTO_INCREMENT = N只能调高起点，无法回收已跳过的值 - 应用层模拟“连续序列”（如用单独序列表）会引入额外锁和事务复杂度，得不偿失
- 基于自增 ID 做分页或范围查询时，跳号反而让逻辑更健壮（避免因误删/回滚导致的重复 ID 冲突）
真正该关注的是：是否影响业务逻辑（比如对外暴露的订单号），而不是数据库内部 ID 是否“好看”。如果必须连续，就别用 AUTO_INCREMENT，改用 UUID、雪花 ID 或业务生成策略。
