深入探究MySQL数据库中Replace Into比Insert更易产生锁的根本原因

在MySQL中，Replace Into 语句相比 Insert 会额外添加一把 LOCK_X 记录锁，原因在于其对唯一索引检查阶段直接施加排他锁，而 Insert 仅加共享锁。当发生冲突时，Replace Into 不会立即释放锁，而是先删除再插入，这使得锁持有时间更长、范围更广，更容易引发死锁。

来看一个核心差异：同样面临唯一键冲突时，普通 Insert 只在检查阶段加一把共享锁，而 Replace Into 一开始就加排他锁。这个差异直接决定了后续锁冲突概率和死锁风险的高低。

Replace Into 为何比 Insert 多加一把 LOCK_X 记录锁

根本原因在于：Replace Into 在唯一索引检查阶段就强制加上了排他锁（LOCK_X），而普通 Insert 仅加共享锁（LOCK_S）。这个细微差别实际上显著放大了锁冲突概率。

具体而言，当出现唯一键（UK）冲突时，InnoDB 在检查 b=8 是否已存在时，Insert 会加 LOCK_S | LOCK_REC_NOT_GAP，允许其他事务并发读取；而 Replace Into 强制加 LOCK_X，禁止其他任何事务对该记录加锁——即便是只读操作也不允许。

• Insert 检查冲突时加 LOCK_S，一旦冲突就报错退出，锁立即释放
• Replace Into 检查冲突时加 LOCK_X，冲突后不立即释放，而是回滚聚集索引插入，再执行 delete 和 insert，全程持有该 LOCK_X
• 若多个 Replace Into 并发争抢同一唯一值（例如都插入 b=8），第一个成功获取 LOCK_X，其余全部等待，极易引发死锁

Replace Into 的两阶段加锁机制导致锁持有时间过长

Replace Into 并非原子操作，它被拆分为“先试插→失败→再删再插”两个阶段，并且第一阶段的锁不会回退，必须等到整个语句执行完毕才释放。

这意味着，即使你只想更新一条已存在的记录，MySQL 也会先尝试插入一行新记录（附带自增 ID），该操作会申请插入意向锁（LOCK_INSERT_INTENTION）和间隙锁（LOCK_GAP），而这些锁在冲突发生后不会立即释放，而是延续到后续的 delete 和 insert 完成。

• Session1 执行 replace into t(b) values (8)，在 b=8 上加 LOCK_X，同时在 (8,100) 区间加上 next-key 锁
• Session2 同样执行，卡在等待 LOCK_X，但它自身已持有部分 gap 锁
• 双方互相等待释放锁，最终形成死锁

Replace Into 删除旧记录会触发更多锁类型

Insert 只涉及插入路径，而 Replace Into 在冲突时必须走 delete 流程，这会触发更多锁行为，包括删除聚集索引行、标记二级索引项、清理 undo log 等，每一步都可能申请新锁。

尤其是当表包含多个唯一索引时，Replace Into 需要依次检查每个唯一键，只要有一个冲突，就可能在多个索引上叠加 LOCK_X；而 Insert 仅在报错前检查一次，并且只锁定命中的索引。

• 当存在联合唯一索引 UNIQUE KEY (a,b) 和单列 UNIQUE KEY (c) 时，Replace Into 可能同时在两个位置加 LOCK_X
• Delete 操作本身会获取聚集索引记录上的 LOCK_X，并且可能触发外键检查锁（如果存在关联外键）
• 自增列（AUTO_INCREMENT）在 Replace Into 中仍然会分配新值（即使最终未使用），受 innodb_autoinc_lock_mode 参数影响，可能引入表级锁竞争

高并发下 Replace Into 更容易暴露锁粒度问题

Insert 是纯粹的新增操作，只要不碰撞唯一键，基本只锁定自身那一行；而 Replace Into 的语义本质是“覆盖”，其锁范围天然更宽——既要防止其他事务插入相同唯一值（gap lock），又要阻止他人修改或删除当前冲突行（record lock），还要为后续的 delete 和 insert 预留空间（insert intention lock）。

这种组合使得 Replace Into 在热点唯一键（如订单号、设备 ID、用户手机号）场景下极易导致锁等待链拉长。特别是当应用层没有控制并发量，也未添加重试机制时，一条失败的 Replace Into 可能阻塞后续数十个请求。

• 当并发量超过 50 QPS 且唯一键重复率超过 20% 时，Deadlock found when trying to get lock 错误出现频率显著增加
• 改用 INSERT ... ON DUPLICATE KEY UPDATE 后，相同场景下死锁几乎消失，因为它执行原地 update，不会触发 delete 阶段的锁扩张
• 如果必须使用 Replace Into，应确保表只有一个唯一索引，并关闭外键、禁用 delete 触发器，否则锁路径会变得更加复杂

实际线上故障时，往往不是单条语句执行慢，而是某条 Replace Into 被卡住后拖垮整个连接池——这一点比锁本身更隐蔽。