Replace Into易死锁因其非原子性，分“试插→删旧→插新”两阶段且全程持LOCK_X排他锁；而Insert On Duplicate Key Update仅在冲突时升级锁，走原地更新，死锁率低一个数量级。
直接结论：别用 REPLACE INTO，改用 INSERT ... ON DUPLICATE KEY UPDATE，并确保唯一索引设计合理、事务粒度可控。
为什么Replace Into在并发下必然容易死锁
它不是原子更新，而是“先试插 → 冲突 → 删旧 → 插新”两阶段操作，且每个阶段都加 LOCK_X（排他锁）：
- 第一阶段试插时，对唯一索引记录加
LOCK_X | LOCK_REC_NOT_GAP，哪怕只是检查冲突，也阻塞其他事务读写 - 冲突后不释放该锁，而是回滚聚集索引插入，再进入第二阶段：检索旧记录、加锁、执行
DELETE + INSERT - DELETE 需要再次对主键和所有唯一索引加
LOCK_X；INSERT 又要申请insert intention lock和gap lock - 多个事务争同一唯一值（如
REPLACE INTO t(b) VALUES (8)），极易形成 A 等 B 的 next-key 锁、B 等 A 的 insert intention 锁的闭环
Replace Into与Insert On Duplicate Key Update的锁行为差异
关键区别不在语义，而在加锁时机和锁类型：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
REPLACE INTO在唯一索引检查阶段就加LOCK_X，冲突后锁不释放，全程持有 -
INSERT ... ON DUPLICATE KEY UPDATE在检查阶段加的是LOCK_S | LOCK_REC_NOT_GAP（共享锁），冲突时才升级为LOCK_X，且只锁命中行，不额外申请 gap 锁 - 后者在冲突路径上走的是原地
UPDATE（非 delete+insert），避免了自增 ID 分配浪费、二级索引重复标记删除等开销 - 实测高并发下，
ON DUPLICATE KEY UPDATE的死锁率通常低于REPLACE INTO一个数量级以上
即使必须用Replace Into，也要规避的硬伤
它不只是死锁问题，还有几个隐性但致命的副作用，常被忽略：
- 每次执行都会消耗一个自增 ID，哪怕最终没插入成功——表里
id会跳变、不连续，下游 binlog 解析或分库分表路由可能出错 - 字段未显式指定时会被置为默认值（如
NOT NULL字段设了DEFAULT 0，就会把原值覆盖成 0） - 存在多个唯一索引时，只要任一 UK 冲突，就会删掉整行——若该行在其他 UK 上也匹配多条记录，可能误删无关数据
- 触发器行为异常：
REPLACE INTO会触发DELETE和INSERT各一次，而业务逻辑通常只预期一次变更
线上已用Replace Into，怎么快速止损
不能立刻改 SQL？优先从架构层收敛风险：
- 加应用层分布式锁（如 Redis 锁），key 为唯一索引值（如
"replace:po_no:PO20261015001"），强制串行化冲突写入路径 - 将高频
REPLACE INTO操作异步化：写入消息队列（如 Kafka），由单消费者线程按唯一键 hash 分区顺序消费，天然避免并发冲突 - 检查
innodb_autoinc_lock_mode是否为2（默认），避免 AUTO_INC 表锁放大阻塞；但注意mode=2下 binlog 格式必须是ROW - 临时降级：把
REPLACE INTO改为先SELECT ... FOR UPDATE判断是否存在，再决定INSERT或UPDATE——虽然多一次网络往返，但锁范围可控、无死锁
最根本的复杂点在于：死锁日志里显示的 “holds the lock” 往往是误导性的（MySQL 5.7 早期版本 bug），真实锁等待链藏在 insert intention 与 next-key lock 的交叉依赖中，靠看日志很难准确定位，必须结合唯一索引结构和并发模式反推。所以，别等死锁报警才动，替换动作越早越好。
