INSERT本身不会直接导致死锁，但在RR隔离级别下因Next-Key Lock与SELECT FOR UPDATE等语句交叉执行且锁序不一致时，易形成循环等待；其根本原因是插入意向锁与间隙锁冲突。
INSERT 本身不会直接导致死锁，但只要它和其它语句（尤其是 SELECT FOR UPDATE、UPDATE、DELETE）在可重复读（RR）隔离级别下交叉执行，且锁获取顺序不一致，就极大概率触发死锁。
为什么 INSERT 会卷入死锁
很多人误以为 INSERT 只加行锁，实际上在 MySQL 的 RR 隔离级别下，InnoDB 对插入位置加的是 Next-Key Lock（行锁 + 间隙锁）。这意味着：两个事务试图往同一索引间隙插入不同记录时，可能各自持有对方需要的插入意向锁（insert intention lock），形成循环等待。
典型链路如下：
- 事务 A 执行
SELECT * FROM orders WHERE order_date = '2026-07-20' FOR UPDATE→ 锁住该值对应记录及前后间隙 - 事务 B 同时执行
INSERT INTO orders (order_id, order_date) VALUES (1001, '2026-07-20')→ 需要同一间隙的插入意向锁 - 事务 C 再执行类似范围更新 → 可能反向持有事务 B 需要的锁
此时三者构成环状依赖，InnoDB 检测后随机回滚一个，并报错 Deadlock found when trying to get lock。
如何快速定位 INSERT 死锁现场
死锁发生后，不能只看报错 SQL，必须还原持锁与等锁上下文：
- 立即执行
SHOW ENGINE INNODB STATUS\G，重点看LATEST DETECTED DEADLOCK区块，它会明确写出两个事务各自的 SQL、锁类型（如lock_mode X locks gap before rec）、索引名和具体锁住的索引值 - 若用 MySQL 5.7+，可查
performance_schema.data_lock_waits表，重点关注BLOCKING_ENGINE_TRANSACTION_ID和REQUESTING_ENGINE_TRANSACTION_ID -
information_schema.INNODB_TRX只显示当前活跃事务，无法还原已回滚的死锁现场，别依赖它
INSERT 死锁的实操修复方式
修复不是改 INSERT 语法，而是调整事务行为和索引设计：
- 避免在
INSERT前做不必要的SELECT FOR UPDATE—— 如果只是为了防重，改用INSERT IGNORE或INSERT ... ON DUPLICATE KEY UPDATE - 确保所有业务逻辑以相同顺序访问索引：比如总是先按
user_id查询/更新，再按order_date插入；禁止有的先查日期、有的先查用户 - 检查二级索引是否包含大字段（如
VARCHAR(2000)或TEXT）：这类字段被INCLUDE进索引时，可能导致锁范围扩大，删掉INCLUDE或改用更小字段类型 - 对高频插入表，考虑关闭自增主键的
innodb_autoinc_lock_mode=2（交错模式），减少 AUTO_INCREMENT 锁竞争
为什么 ON DUPLICATE KEY UPDATE 也会死锁
这个语句看似原子，实则分两步：先尝试插入，若唯一键冲突，则对**已存在行加 S 锁**，再升级为 X 锁执行 UPDATE。当表有多个唯一索引时，InnoDB 检查键的顺序不确定（按索引创建顺序），不同事务可能锁定不同行，进而引发 ABBA 式死锁。
关键风险点：
- 表定义了多个唯一键（如
UNIQUE(email)和UNIQUE(phone)），且并发插入相同 email 但不同 phone 的记录 - 事务 A 先命中 email 索引，锁住某行；事务 B 先命中 phone 索引，锁住另一行；随后双方都试图更新对方刚锁住的行
- 这种“多唯一键 + 并发插入”组合是生产环境最隐蔽的死锁来源之一
真正危险的不是语句本身，而是它把锁行为藏在引擎层——你从应用日志里根本看不出，一条 INSERT ... ON DUPLICATE KEY UPDATE 背后悄悄锁了两行、甚至跨了两个索引。
