replace into必然消耗自增id，因其执行“先删后插”逻辑：冲突时删除旧记录再插入新记录，insert阶段必分配新自增值且不可回退，即使行数不变、显式指定id或冲突发生在非主键字段亦如此。
Replace Into 为什么必然消耗自增ID
因为 REPLACE INTO 的执行逻辑是「先删后插」：只要遇到主键或唯一键冲突，就会触发 DELETE + INSERT 流程。而 INSERT 阶段一定会申请一个新的自增ID，哪怕最终只是替换了已有行。
常见误解是“没新增行，就不该占ID”——但 MySQL 不这么算。它在语句解析阶段就向自增计数器取号，这个动作不可回退，即使后续因冲突触发删除，ID也已消耗。
-
REPLACE INTO t(name) VALUES('a')在name='a'已存在时，仍会让AUTO_INCREMENT加 1 - 返回影响行数为
2 rows affected（删 1 行 + 插 1 行），但表里行数不变 - 如果连续执行两次，
AUTO_INCREMENT会跳过中间值，比如从 5 → 7
主从复制下空洞变成主备不一致
主库和备库对同一条 REPLACE INTO 的执行路径不同：主库走 DELETE + INSERT，备库在 ROW 格式 binlog 下实际执行的是 UPDATE（binlog 把 REPLACE 重写为等效更新）。
关键差异在于：UPDATE 不修改表的 AUTO_INCREMENT 值，而 INSERT 会。结果就是：
- 主库
SHOW CREATE TABLE显示AUTO_INCREMENT = 7 - 备库同表显示
AUTO_INCREMENT = 5（停留在初始值或上次真正插入后的值） - 一旦发生主从切换，新主库用旧
AUTO_INCREMENT继续分配，立刻撞上已存在的 ID，报ERROR 1062 Duplicate entry
和 INSERT IGNORE、ON DUPLICATE KEY UPDATE 的区别
三者都处理冲突，但对自增ID的影响完全不同：
-
INSERT IGNORE：冲突时跳过插入，但自增计数器仍+1（语句执行前就预占ID），产生空洞 -
ON DUPLICATE KEY UPDATE：冲突时只做更新，不触发新INSERT，AUTO_INCREMENT完全不动 -
REPLACE INTO：无论冲突与否，只要语义上涉及插入（哪怕是替换），就一定消耗ID
所以，如果你只想要「存在则更新、不存在则插入」，ON DUPLICATE KEY UPDATE 是更安全的选择；REPLACE INTO 的代价不只是空洞，更是主从元数据分裂的风险。
innodb_autoinc_lock_mode 如何放大这个问题
默认值 innodb_autoinc_lock_mode = 1 在批量 REPLACE INTO ... SELECT 场景下会预分配 ID 段，进一步扩大空洞范围。比如一次插入 100 行，可能提前占用 100~200 个 ID，中间大量未用。
更麻烦的是，REPLACE INTO 和该参数交互时无法预测跳号幅度：
-
innodb_autoinc_lock_mode = 0：全表锁，ID 连续但并发极低，基本不用 -
= 1（默认）：语句级锁 + 预分配，空洞可控但仍有 -
= 2：无锁，高并发下多个线程交错分配，空洞大小完全不可控
真正难处理的不是单次跳号，而是空洞叠加主从不一致后，在故障转移时突然暴露——这时候你查日志只会看到「主键冲突」，却找不到谁插了重复ID。
