replace into在唯一索引上加gap lock是因为其“试插失败”阶段先加lock_x记录锁，该锁自动升级为next-key lock（记录锁+左侧间隙锁），且间隙锁不因后续回滚而释放；而insert on duplicate key update只走查→锁→改/插单路径，无失败重试状态，故不产生额外间隙锁。
REPLACE INTO 为什么会在唯一索引上加 gap lock？
因为 REPLACE INTO 不是原子更新，它在“试插失败”阶段就已对唯一索引加了 LOCK_X 记录锁（不是 LOCK_S），而这个锁会**自动升级为 next-key lock**——即记录锁 + 左侧间隙锁。即使该行最终被删掉重插，这个间隙锁也不会提前释放。
典型场景：表 t(b) 有唯一索引 b，当前存在 b = 8；并发执行 REPLACE INTO t(b) VALUES (8) 时，第一个事务在试插阶段就会在 (5, 8] 或 (8, 12) 这类间隙上持锁，阻塞其他事务向该间隙插入新值（如 b = 6 或 b = 9）。
INSERT ON DUPLICATE KEY UPDATE 为什么没这个问题？
它只走单路径：查→锁→改/插。查到冲突时，直接对冲突行加一把 LOCK_X（next-key 或 record lock，取决于查询条件），不回滚、不释放、不二次申请锁。没有“先加锁再失败再补救”的中间状态，自然不会多出额外的间隙锁。
常见误判点：
- 以为“都涉及唯一键冲突”，锁行为就一样 —— 实际
REPLACE INTO多一次失败路径的锁残留 - 用
EXPLAIN看不出间隙锁 —— 它不体现在执行计划里，只反映在INFORMATION_SCHEMA.INNODB_TRX和死锁日志中 - 在
READ COMMITTED下仍可能遇到 —— 虽然 RC 级别默认禁用间隙锁，但REPLACE INTO在唯一索引等值冲突时仍会加 gap lock（MySQL 行为特例）
怎么确认当前语句是否触发了间隙锁？
最直接的方式是复现并发操作后查 INFORMATION_SCHEMA.INNODB_LOCK_WAITS 和 INNODB_TRX，重点看 TRX_WAITING_LOCK_ID 对应的锁类型是否含 lock_mode X locks gap before rec 或 lock_mode X locks next-key。
辅助验证方法：
- 执行
SELECT * FROM t WHERE b = 8 FOR UPDATE（主键或唯一索引等值）→ 只加 record lock，不加 gap lock - 执行
REPLACE INTO t(b) VALUES (8)→ 查锁信息，大概率看到gap before rec - 对比
INSERT ... ON DUPLICATE KEY UPDATE同样操作 → 锁结构更精简，无 gap before rec
修复间隙锁干扰的实操建议
不要试图“关掉间隙锁”（innodb_locks_unsafe_for_binlog 已废弃，且全局关闭风险极高），而是从语句层规避：
- 把
REPLACE INTO全量替换为INSERT ... ON DUPLICATE KEY UPDATE，这是最彻底的解法 - 确保
ON DUPLICATE KEY UPDATE中显式列出所有需保留/更新字段，避免漏写导致字段值被忽略 - 如果业务逻辑强依赖
REPLACE INTO的“清空未指定列”语义，需额外加一层应用层校验或用DELETE + INSERT显式控制，但务必包在事务里并评估锁范围
真正容易被忽略的是：即使你没写范围条件、没建非唯一索引，只要用了 REPLACE INTO，它就在唯一索引上悄悄加了 gap lock——而且这个锁会持续到事务结束，不是语句结束。
