MySQL并发INSERT死锁常由AUTO-INC锁与唯一键Next-Key Lock双重竞争引发：事务A持AUTO-INC锁等待插入，事务B因唯一冲突持S Next-Key Lock并等待A释放ID，形成循环等待。
并发INSERT触发自增锁与唯一键锁的双重竞争
MySQL在并发INSERT时出现Deadlock found when trying to get lock，往往不是单一锁类型导致，而是AUTO-INC锁和Next-Key Lock在特定条件下形成循环等待。尤其当表含PRIMARY KEY或UNIQUE KEY且使用AUTO_INCREMENT主键时，两个事务可能分别卡在「争抢自增值」和「检测唯一冲突」两个不同锁阶段。
-
AUTO-INC锁是表级锁（即使innodb_autoinc_lock_mode=2也仍会在某些混合插入场景下退化），它阻塞其他事务获取下一个自增值 - 当
INSERT因唯一键冲突失败时，InnoDB会为冲突索引记录加S Next-Key Lock（非仅S锁），该锁会覆盖间隙+记录，可能阻塞相邻插入 - 若事务A持有
AUTO-INC锁并正尝试插入，事务B已持有一个Next-Key Lock在唯一索引上，而B又需等待A释放AUTO-INC锁来生成新ID——此时死锁闭环就形成了
innodb_autoinc_lock_mode=1 vs =2 的实际影响差异
很多人以为设成innodb_autoinc_lock_mode=2（交错模式）就能彻底避免自增锁争用，但现实更复杂：它只对「Simple inserts」跳过表级AUTO-INC锁，而一旦SQL中混入NULL与显式值（如INSERT INTO t(id, name) VALUES (1,'a'), (NULL,'b')），就会触发Mixed-mode insert逻辑，重新启用AUTO-INC锁。
-
innodb_autoinc_lock_mode=1（默认）：Simple inserts用轻量互斥锁，Bulk inserts（如INSERT ... SELECT）仍用表级AUTO-INC锁 -
innodb_autoinc_lock_mode=2：Simple inserts完全不加AUTO-INC锁，但要求binlog_format=ROW；若为STATEMENT格式，会自动降级为mode=1 - 真正危险的是
Mixed-mode inserts——无论mode=1还是2，只要语句里有显式指定部分AUTO_INCREMENT列值，InnoDB就必须同步分配ID，大概率触发表级锁
唯一键冲突如何意外升级为Next-Key Lock等待
关键点在于：哪怕事务隔离级别是READ-COMMITTED，唯一键冲突仍会触发Next-Key Lock，而不是简单的记录锁。这是因为InnoDB必须防止「幻读式重复插入」——即两个事务同时判断「值X不存在」，然后都试图插入X。
- 假设索引上有记录
(10), (20)，事务A执行INSERT INTO t(num) VALUES(15)，会先加Insert Intention Lock在gap (10,20) 上 - 事务B同时执行
INSERT INTO t(num) VALUES(15)，检测到唯一冲突后，会对已存在的num=15记录（或其最近左邻记录）加S Next-Key Lock，范围可能是(10,20] - 如果此时事务C想插入
num=18，它需要gap锁(15,20)，但被B的Next-Key Lock阻塞；而B又在等A提交释放插入行锁——链式等待就此展开
排查死锁日志里最关键的三行线索
看SHOW ENGINE INNODB STATUS\G输出时，不要只盯*** (1) TRANSACTION和*** (2) TRANSACTION，真正暴露根因的是它们下面紧跟着的锁等待描述：
- 找
lock mode S waiting或lock mode X locks rec but not gap waiting——说明正在等一个共享锁或记录锁，大概率来自唯一键冲突 - 找
lock mode AUTO-INC字样——确认是否自增锁参与了死锁环 - 比对两个事务的
index名：如果一个等PRIMARY上的X锁，另一个等num_index上的S锁，基本可断定是「主键插入」和「唯一索引冲突检测」交叉等待
最易被忽略的是：死锁未必发生在同一张表的同一索引上。一个事务可能卡在AUTO-INC锁（表级），另一个卡在UNIQUE索引的Next-Key Lock（行级），而InnoDB把这两类锁视为同等级资源参与死锁检测——这正是它不像纯行锁死锁那样容易直觉理解的原因。
