INSERT ... ON DUPLICATE KEY UPDATE 的锁粒度与死锁风险分析

INSERT ... ON DUPLICATE KEY UPDATE 是MySQL提供的一种便捷语法，当插入的数据遇到唯一键冲突时，会自动执行更新操作而非直接报错，大幅简化了重复数据处理的代码逻辑。不过这条语句的锁行为和普通INSERT、UPDATE存在差异，在高并发场景下容易引发死锁问题，需要开发者对其锁机制有清晰认知。

语句基本执行逻辑

该语句的执行流程可以分为两个核心阶段：首先是尝试执行插入操作，如果插入时检测到唯一键冲突，就会进入更新阶段，对冲突的目标行执行更新。正是因为这两个阶段的切换，导致了其锁行为的特殊性。

我们可以通过一个简单的示例表来观察语句行为，首先创建测试表：

-- 创建测试表，包含自增主键和唯一索引
CREATE TABLE test_user (
    id INT PRIMARY KEY AUTO_INCREMENT,
    user_name VARCHAR(32) NOT NULL,
    age INT DEFAULT 0,
    UNIQUE KEY uk_user_name (user_name)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

执行INSERT ... ON DUPLICATE KEY UPDATE语句的示例：

-- 插入用户数据，若用户名重复则更新年龄
INSERT INTO test_user (user_name, age) VALUES ('zhangsan', 20)
ON DUPLICATE KEY UPDATE age = VALUES(age) + 1;

不同场景下的锁粒度分析

无唯一键冲突场景

当插入的数据没有触发唯一键冲突时，语句的锁行为和普通INSERT一致：

• 对插入的行加排他记录锁（X锁）
• 对自增主键加自增锁（如果表有自增主键）
• 不会锁定其他无关行，也不会产生间隙锁

这种情况下锁粒度很小，并发冲突概率低。

存在唯一键冲突场景

当插入的数据触发唯一键冲突时，锁行为会变得复杂，主要分为两种情况：

冲突的唯一键是主键

此时会对冲突的主键对应的行加排他记录锁，然后执行更新操作，锁粒度仍然是行级锁，只会锁定冲突的那一行数据。

冲突的唯一键是二级唯一索引

这种情况下，除了对二级唯一索引对应的记录加排他记录锁，还会对对应的主键行加排他记录锁。如果更新操作涉及修改唯一索引字段，还会对相关间隙加间隙锁，避免其他事务插入相同唯一键的数据。

可以通过查看事务锁信息来验证，开启两个事务执行冲突插入：

-- 事务1
START TRANSACTION;
INSERT INTO test_user (user_name, age) VALUES ('lisi', 25)
ON DUPLICATE KEY UPDATE age = 30;

-- 事务2，此时会阻塞，等待事务1释放锁
START TRANSACTION;
INSERT INTO test_user (user_name, age) VALUES ('lisi', 26)
ON DUPLICATE KEY UPDATE age = 31;

此时查看information_schema.INNODB_LOCKS表，可以看到事务2在等待事务1持有的uk_user_name唯一索引对应的记录锁。

死锁产生的常见原因

INSERT ... ON DUPLICATE KEY UPDATE的死锁大多发生在多唯一索引、高并发插入更新的场景，常见原因有以下几种：

多唯一索引交叉冲突

如果表有多个唯一索引，两个事务分别插入不同的数据，但触发了对方已经持有的唯一索引锁，就会形成死锁。比如表同时有uk_user_name和uk_email两个唯一索引：

-- 事务1插入，触发uk_user_name冲突，持有uk_user_name的锁
INSERT INTO test_user (user_name, email, age) VALUES ('zhangsan', 'zhangsan@ipipp.com', 20)
ON DUPLICATE KEY UPDATE age = 21;

-- 事务2插入，触发uk_email冲突，持有uk_email的锁，同时等待事务1的uk_user_name锁
INSERT INTO test_user (user_name, email, age) VALUES ('lisi', 'zhangsan@ipipp.com', 22)
ON DUPLICATE KEY UPDATE age = 23;

-- 事务1再插入触发uk_email冲突的数据，等待事务2的uk_email锁，形成死锁
INSERT INTO test_user (user_name, email, age) VALUES ('zhangsan', 'lisi@ipipp.com', 24)
ON DUPLICATE KEY UPDATE age = 25;

间隙锁与记录锁交叉等待

当更新操作涉及唯一索引字段时，语句会加间隙锁防止幻读，此时如果多个事务的插入更新操作交叉覆盖相同间隙，就容易形成死锁。比如两个事务同时插入相邻的唯一键值，都先加了间隙锁，再等待对方的记录锁。

降低死锁风险的方案

针对上述问题，可以采取以下措施降低死锁概率：

• 尽量保证表中只有一个唯一索引，减少多唯一索引交叉锁的概率
• 对插入更新的唯一键字段做幂等性处理，比如先查询是否存在，再决定插入还是更新，避免直接执行INSERT ... ON DUPLICATE KEY UPDATE
• 如果必须使用该语句，尽量缩短事务的执行时间，减少锁的持有时长
• 统一事务中操作数据的顺序，避免交叉等待锁的情况

总结

INSERT ... ON DUPLICATE KEY UPDATE的锁粒度在无冲突时是行级锁，有冲突时根据唯一索引类型不同会锁定对应记录及关联主键行，多唯一索引场景下容易引发死锁。开发者在使用时需要结合业务场景评估锁风险，通过合理的表结构设计和事务控制降低问题发生概率。

MySQLINSERT_ON_DUPLICATE_KEY_UPDATE锁粒度死锁修改时间：2026-06-30 06:33:35