MySQL唯一索引发生Duplicate key冲突时会加什么锁？-mysql教程-PHP中文网

唯一索引冲突时InnoDB会对已存在冲突记录加S锁，而非不加锁；INSERT IGNORE加S锁，ON DUPLICATE KEY UPDATE加X锁，REPLACE INTO则先加X锁再删行。

mysql唯一索引发生duplicate key冲突时会加什么锁？

唯一索引冲突时加的是 S 锁，不是不加锁

很多人误以为 INSERT 失败就“啥也没干”，其实 MySQL（InnoDB，RR 隔离级别）在检测到唯一键冲突的瞬间，就会对**已存在的那条冲突记录**加共享锁（S lock）。这是官方明确行为：Duplicate-key error occurs, a shared lock on the duplicate index record is set。它不是等报错后才释放，而是从冲突判定那一刻起就持有该锁，直到事务结束。

常见错误现象是：多个事务同时 INSERT 同一个已存在邮箱，第二个、第三个事务没立刻报错，反而卡住；用 SELECT * FROM performance_schema.data_locks 查能看到多条 LOCK_MODE: S 记录指向同一行——说明它们都在等升级成 X 锁（比如后续想 UPDATE），但 S 锁之间互不阻塞，升级却会竞争。

主键冲突 → 对主键记录加 S record lock
唯一二级索引冲突 → 对该唯一索引记录加 S record lock，同时可能对主键加 S lock（取决于是否需要回表）
联合唯一索引（如 (a,b)）中 b 为 NULL → 因 NULL 不参与唯一性比较，冲突判断模糊，InnoDB 可能扩大锁范围至 gap 或 next-key

为什么有时看起来像“全表卡死”？其实是间隙锁叠加

所谓“全表锁”是误判。真实情况是：多个事务在争抢**同一个间隙 + 同一唯一值位置**，叠加 next-key 锁机制后，锁范围容易重叠或扩散。典型诱因包括：

WHERE 条件没走唯一索引：比如 email LIKE 'a%' 导致无法精确定位，InnoDB 升级为扫描多个间隙
非唯一索引上做 SELECT FOR UPDATE：查重逻辑被迫锁整个间隙，而非单行
批量插入不同值但落在同一间隙：例如索引值为 10、20、30，事务 A 插 15 并锁 (10,20)，事务 B 插 18 也试图锁 (10,20)，但内部子间隙加锁顺序不一致 → 循环等待

这时 SHOW ENGINE INNODB STATUS 中常出现 lock_mode X locks gap before rec insert intention waiting，说明多个事务在等同一个间隙锁——这几乎总是由 ON DUPLICATE KEY UPDATE 或 REPLACE INTO 引发的，而非单纯 INSERT ... VALUES()。

INSERT IGNORE 和 ON DUPLICATE KEY UPDATE 的锁差异很关键

INSERT IGNORE 冲突时确实不执行 UPDATE，但它底层仍要加插入意向锁和 S 锁；而 ON DUPLICATE KEY UPDATE 在冲突时会对目标行加 X lock（不是 S lock），哪怕 UPDATE 子句是伪更新（如 id=id）也会触发。这意味着：

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

INSERT IGNORE：冲突时加 S lock，释放快，适合“存在即丢弃”的幂等写入
ON DUPLICATE KEY UPDATE：冲突时加 X lock，且必须先获取该锁才能执行 UPDATE，锁持有时间更长，更容易卷入死锁
REPLACE INTO：本质是 DELETE + INSERT，要先加 X lock 删除原行，再申请新行的插入意向锁——锁窗口更大，死锁风险最高

所以不要以为加了 IGNORE 就绝对安全；如果并发量极高、冲突频繁，S 锁堆积本身就能造成明显延迟，尤其当事务里还有其他操作依赖这行数据时。

捕获 1062 错误必须用错误码，不能靠字符串匹配

INSERT IGNORE 会静默忽略所有约束违规，不只是唯一冲突。如果只靠 "Duplicate entry" in str(e) 判断，可能掩盖字段截断、ENUM 越界等真正该报警的问题。正确做法是：

Python 中检查 e.args[0] == 1062
Java 中用 SQLException.getSQLState().equals("23000") 或错误码比对
必须确保只在“插入不存在记录、失败即忽略”的场景下捕获 1062，比如去重日志写入、幂等注册

真正容易被忽略的是：即使你用了 INSERT IGNORE，只要并发插入相同唯一键，仍可能因插入意向锁与已有 S/X 锁等待形成循环等待——日志里没报 Duplicate entry，却出现 Deadlock found when trying to get lock。这时候得看锁视图，而不是只盯错误码。