唯一索引本身不导致死锁，但高并发插入时InnoDB加间隙锁与插入意向锁易形成循环等待；INSERT IGNORE仍需加锁，非无锁跳过；联合索引含NULL、多唯一索引加锁顺序不一致、函数/前缀索引扩大锁范围等均加剧死锁风险。
唯一索引本身不导致死锁，但高并发插入时，InnoDB 对唯一索引的加锁行为（特别是间隙锁 + 插入意向锁的组合）与事务执行顺序不一致，会直接构成循环等待条件。
INSERT IGNORE 并非“无锁跳过”，它照样加插入意向锁
很多人误以为 INSERT IGNORE 遇到唯一冲突就完全不走 InnoDB 的写路径。实际它仍会：先申请插入意向锁（insert intention lock），再尝试获取目标位置的记录锁或间隙锁；若另一事务已持该间隙的 X lock 或 gap lock，就会卡在等待阶段——此时还没报 Duplicate entry，就已经陷入锁等待了。
- 典型日志现象：
Deadlock found when trying to get lock，但应用层没捕获到1062 Duplicate entry - 联合唯一索引（如
(a, b)）中含NULL值时，因NULL不参与唯一性比较，但 gap lock 范围仍重叠，极易触发 - 多个事务同时对同一唯一键值（如手机号）执行
INSERT IGNORE，哪怕最终只有一条成功，过程中的锁竞争已足够形成死锁回路
ON DUPLICATE KEY UPDATE 查找阶段就可能锁住整个间隙
INSERT ... ON DUPLICATE KEY UPDATE 看似原子，但 InnoDB 内部必须先定位是否存在冲突行。这个“查找”动作是否高效，完全取决于 ON DUPLICATE KEY 所依赖字段是否有**唯一索引**：
- 有唯一索引 → 定位为 O(1)，只加目标记录的
X lock，间隙锁收缩为零 - 无索引或仅普通索引 → 全表扫描或范围扫描，对扫描路径上所有“可能插入的位置”加
gap lock，其他事务在相同间隙插入即被阻塞 - 即使最终是更新，查找阶段的锁已发放；若两个事务查找范围重叠、更新顺序相反，死锁立刻成立
多个唯一索引共存时，InnoDB 加锁顺序不一致
一张表若定义了多个唯一索引（如 UNIQUE(email) 和 UNIQUE(phone)），InnoDB 在处理冲突时，内部加锁顺序不保证全局一致。当事务 A 先锁 email 索引再锁 phone，事务 B 反过来操作，就构成经典死锁模板。
- MySQL 不保证多唯一索引之间的加锁顺序，这是引擎实现细节，无法通过 SQL 控制
- REPLACE INTO 更危险：它本质是“删 + 插”，需先获取待删行的
X lock，再申请新行的插入意向锁；两个事务互等对方删除动作，死锁概率远高于INSERT IGNORE - 函数索引、前缀索引会导致实际匹配行为与预期不符，让间隙锁范围意外扩大，排查时容易忽略
真正棘手的不是语法选哪个，而是：唯一索引字段是否被 WHERE 条件精准命中、事务是否按固定顺序访问多索引、以及 NULL 值和函数包裹是否悄悄放大了 gap lock 范围——这些细节在死锁日志里往往只体现为一行 lock_mode X locks gap before rec insert intention waiting，但根子不在锁本身，而在索引设计与访问逻辑的隐式耦合。
