SELECT ... JOIN 会触发死锁，因其可能涉及加锁读（如 FOR UPDATE），当多个事务以不同顺序访问相同资源（行锁、间隙锁等）时便会发生；常见诱因包括驱动表顺序相反、执行计划不一致、索引设计不合理等。
为什么 SELECT ... JOIN 也会触发死锁？
死锁不是只有 UPDATE 或 DELETE 才会发生的——只要多个事务以不同顺序访问相同资源（比如索引页、行锁、间隙锁），SELECT ... FOR UPDATE 或带锁读的关联查询就可能陷入死锁。常见诱因是：两个事务分别先锁表 A 的某几行，再试图锁表 B 的某几行，但顺序相反；或者优化器对同一 JOIN 生成了不同执行路径（如一个走 idx_a_b，另一个走 idx_b_a），导致加锁范围和顺序不一致。
如何让 JOIN 的锁顺序稳定可预测？
核心思路是强制优化器使用确定的驱动表和访问路径，避免因统计信息变化或参数波动导致执行计划漂移。关键操作包括：
- 用
STRAIGHT_JOIN（MySQL）或/*+ LEADING() */（Oracle/PG）显式指定驱动表，确保多表 JOIN 总是从同一张表开始遍历 - 在
ON和WHERE条件中，所有关联字段必须落在同一复合索引的最左前缀上；例如JOIN t1 ON t2.a = t1.a AND t2.b = t1.b，则t1上必须有(a, b)索引，且不能只建(b, a) - 避免在
JOIN条件中使用函数或表达式（如UPPER(t1.name) = t2.name），否则索引失效，优化器可能退化为全表扫描+临时排序，锁粒度扩大
哪些索引设计会让死锁概率飙升？
看似合理的索引，反而会加剧竞争。典型高危模式：
- 两张表各自只建单列索引（如
t1(a)和t2(a)），而JOIN条件是t1.a = t2.a—— 优化器可能选择不同索引做驱动，锁顺序不可控 - 冗余索引重叠严重，例如同时存在
(a)、(a,b)、(a,b,c)，优化器在数据倾斜时可能选错索引，导致部分事务走范围扫描、部分走等值查找，锁区间不一致 - 缺失
WHERE过滤字段的联合索引，迫使优化器先完成大结果集JOIN，再过滤，过程中锁住大量无关行
实操建议：用 EXPLAIN FORMAT=TRADITIONAL 对比不同事务的执行计划，重点看 key、rows 和 Extra 中是否出现 Using temporary; Using filesort —— 这类操作往往伴随更宽的锁范围。
READ COMMITTED 隔离级别真能避免 JOIN 死锁吗？
不能。虽然 READ COMMITTED 会释放非匹配行的记录锁（相比 REPEATABLE READ），但它不消除间隙锁（Gap Lock）和 Next-Key 锁，尤其在 JOIN ... WHERE ... BETWEEN 或 ORDER BY ... LIMIT 场景下，间隙冲突依然存在。更关键的是：死锁本质是加锁顺序冲突，而非隔离级别高低。
真正有效的缓解手段是：
- 将长事务拆成多个短事务，减少持有锁的时间窗口
- 在应用层统一
JOIN涉及表的更新/查询顺序（例如始终先操作order表，再操作order_item） - 监控
InnoDB_deadlocks状态变量 +SHOW ENGINE INNODB STATUS中的LATEST DETECTED DEADLOCK，定位具体 SQL 和锁等待链
最常被忽略的一点：即使 SQL 完全一样，如果参数值导致优化器选择了不同索引（比如 WHERE status = ?，当 ? 是 ‘pending’ 时走索引，是 ‘done’ 时因高重复率走全表），锁行为就完全不同——这种隐式不确定性，比语法错误更难排查。
