replace into 比 insert 多加 lock_x 记录锁，因其在唯一索引检查阶段即加排他锁，而 insert 加共享锁；冲突时 replace 仍持 lock_x 执行删插，导致锁冲突概率高、易死锁，且多唯一索引时锁扩散更严重。
REPLACE INTO 为什么比 INSERT 多加一把 LOCK_X 记录锁
因为 REPLACE INTO 在唯一索引检查阶段就加的是排他锁（LOCK_X），而普通 INSERT 加的是共享锁（LOCK_S）。这个差异直接放大了锁冲突概率。
具体来说：
- 当遇到唯一键（UK）冲突时，
INSERT会加LOCK_S | LOCK_REC_NOT_GAP，允许其他事务并发读 -
REPLACE INTO则强制加LOCK_X，禁止任何其他事务对同一记录加锁——哪怕只是读 -
INSERT检查冲突 → 加LOCK_S→ 冲突则报错退出，锁很快释放 -
REPLACE INTO检查冲突 → 加LOCK_X→ 冲突后不立即释放，而是回滚聚集索引插入、再尝试DELETE + INSERT，全程持有该LOCK_X
并发 REPLACE INTO 为什么会触发两次 X 锁
REPLACE INTO 不是原子操作，它被拆成「先试插 → 失败 → 再删再插」两个阶段，但第一阶段加的锁不会回退，要等到整个语句执行完才释放。
这意味着：
- 即使你只是想更新一条已存在的记录，MySQL 仍会先尝试插入一条新行（带自增 ID），这个动作会申请插入意向锁（
LOCK_INSERT_INTENTION）和间隙锁（LOCK_GAP），而这些锁在冲突发生后并不会立刻释放 - Session1 执行
replace into t(b) values (8)→ 在b=8上加LOCK_X，同时在(8,100)区间加 next-key 锁 - Session2 同样执行 → 卡在等待
LOCK_X，但它自己也已持有了部分 gap 锁 - 双方互相等待对方释放锁，死锁形成
有多个唯一索引时 REPLACE INTO 的锁扩散更严重
当表有联合唯一索引 UNIQUE KEY (a,b) 和单列 UNIQUE KEY (c) 时，REPLACE INTO 可能同时在两处加 LOCK_X。
原因在于：
-
REPLACE INTO需要依次检查每个唯一索引，只要有一个冲突，就可能在多个索引上叠加LOCK_X - 而
INSERT只会在报错前检查一次，且只锁命中索引 - 删除旧记录会触发额外锁类型：删除聚集索引行、标记二级索引项、清理 undo log 等，每一步都可能申请新锁
- 如果有关联外键，
DELETE还会触发外键检查锁
INSERT ON DUPLICATE KEY UPDATE 为什么更安全
INSERT ... ON DUPLICATE KEY UPDATE（ODKU）走的是单路径“查 → 锁 → 改/插”，全程最多持两个行级锁。
它的行为更可控：
- 查到 UK 冲突：只对冲突行加一把
LOCK_X（非两次） - 执行
UPDATE：复用已有锁，不新增 - 查不到冲突：等效普通
INSERT，只加必要行锁和 gap lock，无DELETE阶段 - 没有“先插失败再补救”的中间状态，锁生命周期短、范围确定、无锁升级
真正容易被忽略的是语义差异：REPLACE INTO 会把未显式指定的字段设为默认值或 NULL；ON DUPLICATE KEY UPDATE 只更新 UPDATE 子句中列出的字段。业务若依赖返回值判断是否更新，必须重写逻辑——REPLACE INTO 插入返回 1，删除+插入返回 2；ODKU 插入返回 1，更新返回 2。
