死锁本质是事务间循环等待资源，与并发量无关；主因包括加锁顺序不一致、非唯一索引引发间隙锁冲突、索引失效导致锁范围扩大，以及“查-判-插”逻辑中间隙锁与插入意向锁互斥。
低并发下照样死锁，不是并发量的问题，而是锁行为本身是否形成循环等待。InnoDB 的死锁检测机制对「并发高低」不敏感，只看事务间是否构成资源依赖闭环。
为什么SELECT ... FOR UPDATE在单条查询时就可能触发死锁
很多人以为只有高并发批量操作才容易死锁，其实单个 SELECT ... FOR UPDATE 在 RR 隔离级别下，只要命中非唯一索引，就会加 Next-Key Lock（记录锁 + 间隙锁），而间隙锁的范围是动态计算的——两个事务哪怕只查一个值，也可能锁住同一段间隙。
- 例如表中有
order_no普通索引，当前数据为[1001, 1003, 1005]，事务 A 执行SELECT ... FOR UPDATE WHERE order_no = 1004，会锁住间隙(1003, 1005) - 事务 B 同样执行
WHERE order_no = 1004，也会尝试锁同一间隙 → 双方都在等对方释放间隙锁，死锁立即发生 - 即使两个请求间隔几秒、完全不重叠，只要锁未释放（事务未提交），后一个请求仍可能被卡住并最终触发死锁检测
INSERT ... SELECT 或幂等校验逻辑自带死锁风险
典型场景是「先查后插」的幂等控制：用 SELECT ... FOR UPDATE 判断记录不存在，再 INSERT。问题在于，这个「查」锁的是间隙，而「插」要往同一间隙写入——插入操作本身也要获取该间隙的插入意向锁（INSERT_INTENTION），与已有间隙锁冲突。
- 事务 A 查
order_no = 1007→ 锁间隙(1005, 1009) - 事务 B 同样查
order_no = 1007→ 等待该间隙锁 - 此时事务 A 执行
INSERT ... VALUES (1007)→ 需要插入意向锁，但该意向锁与事务 B 的等待状态形成循环 - InnoDB 检测到后，回滚其中一个事务（通常是 undo 小的那个）
索引失效导致锁粒度爆炸式扩大
低并发时如果某条 SQL 意外没走索引，InnoDB 会退化为逐行扫描并加记录锁，相当于对整张表的主键索引“挨个上锁”。这时候哪怕只有一个其他事务在更新任意一行，都可能因锁范围重叠而死锁。
-
WHERE status = 'pending'字段无索引 → 全表扫描加 X 锁 - 另一事务执行
UPDATE ... WHERE id = 123（主键更新）→ 加该行记录锁 - 前者已持有 id=123 行的锁（因扫描到它），后者又在等前者释放；前者又在等后者释放后续某行（比如 id=456）——循环形成
- 这种死锁在 QPS
真正危险的不是并发数，而是事务是否在不可控的间隙上加锁、是否因缺失索引把行锁升级成“伪表锁”、以及业务逻辑是否隐含了多点加锁却未约定顺序。这些因素在低流量时段反而更难被监控覆盖，等发现时往往已在线上静默发生多日。
