自增id出现空洞是正常现象，不是bug；因插入失败、回滚、批量预分配或insert ignore/on duplicate key update等操作导致id跳号，属innodb为并发性能做的取舍。
自增ID出现空洞是正常现象，不是bug
MySQL的AUTO_INCREMENT机制天生不保证连续性。只要发生插入失败、事务回滚、批量预分配或REPLACE/INSERT ... ON DUPLICATE KEY UPDATE，ID就可能跳号。这不是配置错误，也不是数据损坏，而是InnoDB为并发性能做的取舍。
常见空洞场景包括：
– 执行INSERT INTO t VALUES (100, 'a')后又回滚
– INSERT IGNORE遇到唯一键冲突，但自增计数器已加一
– innodb_autoinc_lock_mode=1（默认）下批量插入时预分配ID段
innodb_autoinc_lock_mode参数决定空洞频率和并发表现
这个参数控制自增ID如何分配，直接影响空洞大小和写入吞吐：
-
0：传统锁模式，全表级AUTO_INC锁，严格连续但并发差，基本只用于兼容老版本 -
1：默认值，语句级锁+预分配，多数场景下平衡了性能与可预测性，但批量插入（如INSERT ... SELECT）会一次申请多段ID，容易产生较大空洞 -
2：无锁模式，最高并发，但主从复制必须用ROW格式，且空洞最不可控——同一语句内多个线程可能交错分配ID
查当前值：SELECT @@innodb_autoinc_lock_mode;；改配置需重启或动态设置（5.7+支持SET GLOBAL innodb_autoinc_lock_mode = 2;，但注意主从一致性）
INSERT IGNORE / ON DUPLICATE KEY UPDATE导致ID跳号却没插入数据
这是最容易被误解的空洞来源：语句执行前就消耗了一个ID，即使最终因唯一键冲突没写入任何行。
例如：
INSERT IGNORE INTO users (id, name) VALUES (NULL, 'alice');
若name字段有唯一索引且值已存在，id仍会自增，但行未插入。类似地，INSERT ... ON DUPLICATE KEY UPDATE也会触发ID分配。
应对思路：
– 不依赖ID连续性做业务逻辑（比如分页、范围查询）
– 避免在高冲突场景下用IGNORE做“存在则跳过”逻辑，改用SELECT ... FOR UPDATE + 显式判断
– 若必须用，接受ID空洞，监控空洞率（可用SELECT MAX(id) - COUNT(*) FROM table粗略估算）
想“修复”空洞？通常不值得，且风险远大于收益
人工重排ID（如导出再导入、用变量重赋值）会引发一连串问题：
- 外键约束断裂，除非先禁用
FOREIGN_KEY_CHECKS并确保所有关联表同步更新 - 主从延迟或复制中断，尤其在GTID模式下可能造成事务冲突
- 应用层缓存或日志中残留旧ID，导致数据错乱
- 大表重建耗时长、锁表久，线上几乎不可行
真正需要关注的是：ID是否用尽（INT类型最大值约21亿）、是否影响分库分表路由逻辑、或者是否被下游系统误当作“数据量”指标。其他情况，空洞只是MySQL在后台默默优化并发的副产品。
