死锁是事务间循环等待锁导致InnoDB主动回滚一方，常见于非唯一索引范围操作；唯一索引等值更新几乎不发生；innodb_lock_wait_timeout不影响死锁检测，真正相关的是innodb_deadlock_detect。
死锁不是“卡住”，而是两个事务互相等对方释放锁
MySQL死锁发生时，SHOW ENGINE INNODB STATUS 里一定会看到类似 Deadlock found when trying to get lock 的错误。这不是某个事务太慢，而是两个（或多个）事务各自持有一部分锁，又同时申请对方持有的锁，形成循环等待——InnoDB 检测到后会主动杀掉其中一个事务回滚，让另一个继续。
最常见的触发场景：非唯一索引 + 范围更新 + 并发插入/更新
比如表有字段 status（非唯一索引），两个事务同时执行：
UPDATE orders SET amount = 100 WHERE status = 'pending';
InnoDB 会对满足条件的记录加行锁，但还会在索引间隙（gap）上加锁防止幻读。如果事务 A 锁了 gap1，事务 B 锁了 gap2，而它们下一步又试图插入或更新彼此 gap 中的值，就可能交叉加锁导致死锁。
- 唯一索引上的等值更新（如
WHERE id = 123）几乎不会死锁，因为只锁单行 - 非唯一索引 + 范围条件（
>、BETWEEN、LIKE 'abc%'）是高危组合 - INSERT ... ON DUPLICATE KEY UPDATE 在有唯一键冲突时，也可能因先插入意向锁、再尝试更新而卷入死锁
innodb_lock_wait_timeout 不影响死锁检测，它只管“等锁超时”
很多人误以为调大 innodb_lock_wait_timeout 能避免死锁——其实它完全不相关。这个参数控制的是“一个事务等待锁超过多少秒就报 Lock wait timeout exceeded”，而死锁检测是独立机制，由 InnoDB 每隔 1 秒左右扫描锁等待图，一旦发现环就立刻处理。
- 死锁检测开销小，不必关闭；关掉反而会让死锁变成无限等待（直到超时）
- 真正要调的参数是
innodb_deadlock_detect（默认 ON），极少数超高并发写场景可关，但必须配合应用层重试逻辑 - 死锁日志只保留最近一次，看历史死锁得靠监控抓取
SHOW ENGINE INNODB STATUS输出
查死锁不能只看 SQL，得看锁类型和索引结构
同一句 UPDATE 在不同索引设计下锁的范围差异极大。例如：
- 没索引的
WHERE name = 'alice'→ 全表扫描，锁所有行（甚至可能升级为表锁） - 有普通索引但不是覆盖索引 → 锁索引记录 + 对应主键记录
- 有联合索引
(status, created_at)，但查询只用WHERE status = 'pending'→ 可能锁整个索引段，范围远超预期
所以遇到死锁，第一步不是改 SQL，而是用 EXPLAIN 看执行计划，确认走哪个索引、是否用了索引下推、有没有回表——这些直接决定锁什么、锁多少。
