INSERT在唯一键冲突时会对已存在记录加共享锁（S lock），而非不加锁；并发多个事务持S锁等待升级为X锁，叠加间隙锁重叠，易形成死锁闭环，并非真正全表锁。
唯一索引插入本身不会全表加锁，但并发冲突时可能触发共享锁（S lock）+ 间隙锁（gap lock）组合，形成死锁闭环；所谓“全表锁”是误判，实际是多个事务在相同间隙反复争抢导致锁范围扩散、表现像卡死。
INSERT INTO ... VALUES() 在唯一键冲突时到底加了什么锁
很多人以为“插入失败就啥也不锁”，其实 MySQL（InnoDB，RR 隔离级别）在检测到唯一键冲突时，会在**已存在的冲突记录上加共享锁（S lock）**，而不是直接报错退出。这是官方明确行为：Duplicate-key error occurs, a shared lock on the duplicate index record is set。
- 两个事务同时执行
INSERT INTO user (email) VALUES ('a@test.com')，而该邮箱已存在 - 第一个事务成功插入并持 X 锁（很快提交）
- 第二个事务发现冲突，但它不是立刻失败，而是对已有记录
'a@test.com'加 S 锁，准备做后续处理（比如判断是否可覆盖） - 如果此时第一个事务回滚（释放 X 锁），第二个事务的 S 锁还在；第三个并发事务也来插同一邮箱，同样加 S 锁 → 三个 S 锁互不兼容升级为 X 锁 → 死锁检测器介入，选一个回滚
为什么看起来像“全表锁”甚至阻塞无关插入
根本原因不是锁了整张表，而是多个事务在争抢**同一间隙 + 同一唯一值位置**，叠加 next-key 锁机制后，锁范围容易重叠或扩散。典型诱因：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- WHERE 条件没走唯一索引：比如用
SELECT ... FOR UPDATE WHERE email LIKE 'a%'（email是 UNIQUE KEY，但 LIKE 前缀模糊导致无法精确定位），InnoDB 会升级为扫描多个间隙，锁住 (prev, next) 区间 - 非唯一索引上做
SELECT FOR UPDATE：如订单表只在order_no上建了普通 INDEX 而非 UNIQUE，此时查重会锁整个间隙，而非单行 - 批量插入不同值但落在同一间隙：例如索引值为 10、20、30，事务 A 插 15 并锁 (10,20)，事务 B 插 18 也试图锁 (10,20)，但内部子间隙加锁顺序不一致 → 循环等待
ON DUPLICATE KEY UPDATE 和 INSERT IGNORE 的锁行为差异
二者都比“先查后插”安全，但锁策略不同，影响并发吞吐：
-
INSERT IGNORE：冲突时直接丢弃，不加 S 锁，也不触发后续逻辑；性能高，但无法返回“是否已存在”的状态 -
INSERT ... ON DUPLICATE KEY UPDATE：冲突时会对冲突行加 X 锁（不是 S 锁），然后执行 UPDATE；适合需要幂等更新的场景，但若 UPDATE 字段无索引，可能引发额外锁等待 - ⚠️ 注意：
REPLACE INTO实质是 DELETE + INSERT，在有外键或触发器时会更重，且 DELETE 操作会释放原记录锁但可能引发其他事务的 gap lock 重算，反而增加死锁概率
最容易被忽略的底层陷阱：事务粒度与索引定义强耦合
死锁是否爆发，不只看 SQL 写法，更取决于索引结构和事务内操作顺序：
- 同一个业务键，如果在表里同时存在 PRIMARY KEY 和 UNIQUE KEY 两个约束，MySQL 可能按不同顺序尝试加锁，增加不确定性
- 事务里混用
SELECT FOR UPDATE和INSERT，且 SELECT 条件未强制走唯一索引（例如用了函数、隐式转换），就会从行锁退化为 gap lock 扫描 - 应用层重试逻辑若没控制最大次数或退避时间，高频重试会让锁竞争雪球式放大，把原本偶发的 1213 变成持续性故障
真正稳的方案，从来不是靠调大 innodb_lock_wait_timeout 或关死锁检测，而是让每次插入都落在唯一索引的单点定位上，并确保事务里没有其他非必要锁操作——否则再细的锁粒度，也会被错误的执行路径拖垮。
