IN/EXISTS子查询易触发死锁，本质是InnoDB执行时加锁顺序不可控：子查询可能全扫并加间隙锁，与主查询形成AB-BA等待环；改用JOIN可统一加锁路径，配合索引覆盖可根治。
WHERE子句中IN/EXISTS子查询为什么容易触发死锁
不是子查询语法本身有问题，而是InnoDB在执行这类语句时，可能对子查询结果集提前加锁，且加锁顺序与主查询不一致。比如UPDATE t1 SET x=1 WHERE id IN (SELECT id FROM t2 WHERE status=1)，优化器可能先全扫t2并加间隙锁，再回表t1更新；而另一个事务若先锁t1某几行、再查t2，就形成AB-BA等待环。
常见现象是报错Deadlock found when trying to get lock，但SQL看起来“完全合法”，且复现不稳定——这正是嵌套查询加锁路径不可控的典型表现。
- 子查询若含范围条件（如
WHERE create_time > '2026-01-01'），在REPEATABLE READ下会触发间隙锁，锁住整个索引区间，大幅扩大冲突面 - 当子查询依赖外部表字段（如
WHERE id IN (SELECT t2.ref_id FROM t2 WHERE t2.user_id = t1.user_id)），InnoDB可能对每个匹配的t2行逐条加锁，顺序由索引扫描决定，极易与其它事务错开 - ORM自动生成的子查询常无固定排序，
IN列表内ID顺序每次不同，导致底层行锁获取顺序随机
SHOW ENGINE INNODB STATUS里怎么看子查询引发的死锁
执行SHOW ENGINE INNODB STATUS\G后，直接跳到LATEST DETECTED DEADLOCK区块。重点不是看SQL文本，而是比对两个事务的HOLDING和WAITING FOR部分：
若发现一个事务HOLDING RECORD LOCKS on index `idx_status` of table `t2`，同时WAITING FOR RECORD LOCKS on PRIMARY of table `t1`；另一个事务反过来HOLDING PRIMARY of `t1`又WAITING FOR idx_status of `t2`，基本可断定是子查询跨表加锁顺序不一致所致。
- 注意
index名而非表名——死锁往往发生在二级索引上，比如t2.status有索引但t1.id没走主键，就会锁二级索引+聚簇索引两层 - 若看到
GAP LOCK或NEXT KEY LOCK出现在子查询涉及的索引上，说明范围条件+RR隔离级正在放大锁粒度 - 事务堆栈里若出现
evaluating subquery或materializing subquery字样，就是子查询被物化时加锁的明确信号
用JOIN重写子查询能避免死锁吗
能，而且是最推荐的实操手段。因为JOIN强制优化器生成确定性执行计划，使加锁顺序可预期、可复现。
把UPDATE t1 SET flag=1 WHERE id IN (SELECT id FROM t2 WHERE active=1)改成：
UPDATE t1 INNER JOIN t2 ON t1.id = t2.id SET t1.flag = 1 WHERE t2.active = 1;
这样InnoDB会按t2的索引顺序扫描，再关联t1，所有事务都走同一路径，消除了交叉加锁可能。
- 必须确保
JOIN条件字段有索引，否则仍会退化为全表扫描加锁 - 如果原
IN子查询本就带ORDER BY或LIMIT，重写后需额外验证是否等价——JOIN默认不保序，必要时加ORDER BY t2.id再LIMIT - 对
NOT IN或NOT EXISTS，改用LEFT JOIN ... WHERE t2.id IS NULL，逻辑等价且加锁路径同样可控
READ COMMITTED能缓解子查询死锁吗
能缩小锁范围，但不能根除，且可能引入新问题。
READ COMMITTED下，InnoDB不加间隙锁，只锁实际命中的行。这意味着子查询里的WHERE status=1不会锁住status=1附近的空隙，降低了与插入事务的冲突概率。
- 仅对当前会话生效：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED，别漏掉SESSION - 子查询执行时机可能变化：RR下常被延迟执行（consistent read），RC下可能提前物化为临时表，导致加锁更早、更集中
- 如果业务依赖RR的可重复读语义（比如事务中多次读取同一张表中间状态），降级后可能出现幻读，逻辑出错比死锁更难排查
- 真正治本的不是换隔离级别，而是让子查询本身不参与更新逻辑——先
SELECT出ID列表，在应用层判断后再发批量UPDATE，彻底剥离DB层锁竞争
子查询死锁最隐蔽的地方在于：它不总在SQL语法层面暴露问题，而藏在执行计划和锁行为的细微差异里。比起反复调参，优先用JOIN收口加锁路径，再配合索引覆盖和事务瘦身，才能稳定压住问题。
