REPLACE INTO在唯一索引检查阶段即加LOCK_X排他锁，而非冲突后加锁；其“试插→删再插”两阶段非原子执行导致锁不释放、间隙锁残留、自增ID消耗及多索引并发加锁，极易引发死锁。
REPLACE INTO 在唯一索引检查阶段就加 LOCK_X 锁
普通 INSERT 遇到唯一键冲突时，只加 LOCK_S（共享锁），允许其他事务并发读；而 REPLACE INTO 一上来就在唯一索引记录上加 LOCK_X（排他锁），连读都不让——哪怕你只是想查一下“这条记录存不存在”。
这意味着：两个并发的 REPLACE INTO 同时检查 b = 8，第一个拿到 LOCK_X，第二个直接卡住等待。但第二个事务在等待前，可能已经持有了自己的间隙锁或插入意向锁，形成互相等待的基础。
- 加锁时机早：不是等冲突确认后才锁，而是检查阶段就锁
- 锁粒度粗：
LOCK_X会同时作用于唯一索引记录和对应聚集索引行 - 无条件升级：即使最终走的是 UPDATE 路径（非 DELETE+INSERT），也已提前加了 X 锁
REPLACE INTO 不是原子操作，而是“试插 → 冲突 → 删再插”两阶段
REPLACE INTO 看似一条语句，InnoDB 层实际拆成至少两个逻辑阶段：先尝试插入（会分配新自增值、申请插入意向锁、加 gap 锁），失败后再删除旧行、插入新行。第一阶段加的锁不会回退，要等到整条语句执行完才释放。
这就导致：即使你只想更新一行，MySQL 仍会先在 (8,100) 区间加 next-key 锁，同时对聚集索引新分配的 ID 加记录锁——这些锁在 delete + insert 完成前一直挂着。
- 自增 ID 仍会消耗：每次
REPLACE INTO都触发innodb_autoinc_lock_mode=1下的互斥分配，ID 不连续且不可控 - 间隙锁残留：试插失败后，gap 锁和插入意向锁不立即释放，持续参与死锁检测
- 多唯一索引更危险：若表有
UNIQUE KEY (a,b)和UNIQUE KEY (c)，冲突时可能在多个索引上同时持有LOCK_X
DELETE + INSERT 路径激活更多锁行为
当存在外键、触发器、或非最后一个唯一索引冲突时，REPLACE INTO 必须走 DELETE + INSERT 而非 UPDATE。DELETE 操作本身会重新获取聚集索引上的 LOCK_X，并触发二级索引项标记删除、undo log 清理等动作，每步都可能申请新锁。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
尤其要注意：DELETE 会释放原记录锁，但 gap 锁范围可能重算，引发其他事务的锁等待链延长——这不是“锁少了”，而是“锁动得更复杂了”。
- 外键约束会额外加锁：如被引用表有 ON DELETE CASCADE，可能触发关联表的锁申请
- 触发器内 SQL 可能引入新锁路径，放大死锁面
- 隐藏主键场景（无显式 PK）下，InnoDB 自动生成的聚簇索引行锁与唯一索引锁叠加，锁竞争更隐蔽
用 INSERT ... ON DUPLICATE KEY UPDATE 替代时的关键差异
INSERT ... ON DUPLICATE KEY UPDATE 同样在唯一索引检查时加 LOCK_X，但它不走 DELETE + INSERT，而是原地 UPDATE 行数据，避免了聚集索引重建、二级索引项重插、自增 ID 浪费等副作用。
更重要的是：UPDATE 路径下，锁持有时间更短，且不会在间隙中留下插入意向锁残留——这对高并发写入就是决定性差异。
- 返回值不同：
REPLACE INTO冲突时返回 2 行影响；ON DUPLICATE KEY UPDATE冲突时只返回 2（UPDATE 影响 1 行），但语义更清晰 - 自增列安全：
ON DUPLICATE KEY UPDATE不分配新自增值，避免 ID 跳变和耗尽风险 - 触发器行为可控：UPDATE 触发
UPDATE触发器，而非DELETE+INSERT各触发一次
真正棘手的不是“会不会死锁”，而是死锁日志里显示的 HOLDS THE LOCK 往往是误导——实际是锁还没拿到，但等待链已经闭环。这种非对称加锁节奏，在没有显式事务控制、又依赖唯一索引做 Upsert 的场景下，几乎必然成为瓶颈点。
