REPLACE INTO加两次X锁，因其执行“先试插→冲突回滚→再检索并重加X锁”两阶段流程，第一阶段二级唯一索引已持LOCK_X不释放，第二阶段再对UK及主键记录加LOCK_X或next-key lock，导致高并发下易因insert intention lock与next-key lock互相等待而死锁。
REPLACE INTO 的锁风险高，根本不是“加得不够快”，而是它必须加两次 X 锁，且中间不释放——这在并发场景下天然构成死锁温床。
REPLACE INTO 为什么加两次 X 锁？
它不是原子更新，而是分阶段执行：
第一阶段：尝试 INSERT，发现唯一键（UK）冲突后回滚聚集索引插入，但**二级唯一索引上已加了 LOCK_X 记录锁（不是 LOCK_S）**，这个锁不会随回滚释放；
第二阶段：Server 层收到 DB_DUPLICATE_KEY 后，重新检索冲突行，再对**该 UK 记录 + 对应主键记录，再次加 LOCK_X 或 next-key lock**，为后续 DELETE + INSERT 做准备。
一次冲突的 REPLACE INTO 实际持有 2～3 把 X 级别锁，跨聚集索引和二级索引。
并发 REPLACE INTO 死锁的典型链路
死锁核心来自 insert intention lock 和 next-key lock 的互相等待：
- Session A 执行 REPLACE INTO t(b) VALUES (8)，在 b=8 上加了 next-key X lock，初始插入失败但锁未释放
- Session B 同时执行相同语句，被 A 的 next-key lock 阻塞，进入等待
- Session A 进入第二阶段，需申请 insert intention lock 来重插新记录，但该意向锁范围与 B 持有的锁重叠
- 结果：A 等 B 释放 next-key lock，B 等 A 释放 insert intention lock → 死锁触发
INSERT ON DUPLICATE KEY UPDATE 为什么更安全？
它走的是单路径“查→锁→改/插”，全程最多持两个行级锁：
- 查到 UK 冲突：只对冲突行加一把 LOCK_X（非两次）
- 执行 UPDATE：复用已有锁，不新增
- 查不到冲突：等效普通 INSERT，只加必要行锁和 gap lock，无 delete 阶段
- 没有“先插失败再补救”的中间状态，锁生命周期短、范围确定、无锁升级
替换时最容易忽略的语义差异
REPLACE INTO 和 INSERT ... ON DUPLICATE KEY UPDATE 表面功能相似，但行为差异直接影响数据正确性：
- REPLACE INTO 会把未显式指定的字段设为默认值或 NULL；ON DUPLICATE KEY UPDATE 只更新 UPDATE 子句中列出的字段，漏写 = 字段被忽略
- 返回值不同：REPLACE INTO 插入返回 1，删除+插入返回 2；ON DUPLICATE KEY UPDATE 插入返回 1，更新返回 2 —— 若业务用返回值判断是否发生更新，必须重写逻辑
- 多唯一索引时，两者都只响应第一个触发冲突的索引，但需确认业务是否隐式依赖“哪个索引先命中”的顺序
真正麻烦的不是“要不要换”，而是“换完才发现字段被悄悄清空”或者“返回值判断逻辑崩了”。锁问题能靠语句替换快速收敛，语义坑却要逐条字段核对。
