死锁源于并发事务对资源加锁顺序不一致，嵌套查询仅使该问题更隐蔽；应通过SHOW ENGINE INNODB STATUS分析锁信息，优先用JOIN重写子查询、缩短事务、避免非DB操作，并合理设置隔离级别与索引。
死锁不是SQL写错了，是事务调度撞上了
SQL嵌套查询本身不会直接导致死锁，真正触发死锁的是多个事务并发执行时，对同一组资源（比如表、索引键、间隙）按不同顺序加锁，又互相等待对方释放——嵌套查询只是让这种“加锁顺序不一致”更隐蔽。常见现象是 Deadlock found when trying to get lock 报错，且往往复现不稳定。
实操建议：
- 用
SHOW ENGINE INNODB STATUS\G立刻查最后一次死锁详情，重点看TRANSACTIONS部分里两个事务各自持有哪些锁、正在等哪个锁 - 嵌套查询中若含
UPDATE或DELETE，尤其当子查询依赖外部表条件（如WHERE id IN (SELECT ...)），InnoDB 可能对子查询结果集提前加锁，而主查询再按另一顺序扫描，就容易形成环 - 避免在事务里混用
SELECT ... FOR UPDATE和嵌套子查询更新逻辑；优先把子查询结果先SELECT出来，在应用层做判断和拼接
READ COMMITTED 能缓解但不能根除嵌套死锁
MySQL 默认隔离级别 REPEATABLE READ 会使用间隙锁（gap lock）防止幻读，这在嵌套查询涉及范围条件（如 BETWEEN、>=）时，大幅扩大锁粒度，增加死锁概率。切换到 READ COMMITTED 后，InnoDB 不加间隙锁，只锁实际命中行，锁范围变小。
但注意：
-
READ COMMITTED下，嵌套子查询的执行时机可能变化（例如子查询被物化为临时表），导致加锁顺序仍不可控 - 如果业务依赖
REPEATABLE READ的一致性快照（比如多次读取中间状态），降级隔离级别可能引发逻辑错误 - 仅对当前会话生效需显式设置：
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED
用 JOIN 重写 IN/EXISTS 嵌套，统一加锁路径
很多死锁源于 UPDATE t1 SET x=1 WHERE id IN (SELECT id FROM t2 WHERE ...) 这类语句：优化器可能先扫 t2 加锁，再回表 t1；而另一个事务先锁 t1 再关联 t2，路径冲突。
改用显式 JOIN 能强制执行计划稳定，也让加锁顺序可预期：
UPDATE t1 JOIN t2 ON t1.id = t2.id AND t2.status = 'pending' SET t1.processed = 1;
关键点：
- 确保
JOIN条件字段都有索引，否则全表扫描会锁住更多行 - 如果
t2数据量大，考虑加LIMIT分批更新，缩短事务持有锁时间 - 避免在
JOIN中引用未索引的计算字段或函数，如DATE(created_at)，会导致索引失效和锁升级
事务越短越好，嵌套查询别拖进大事务
嵌套查询本身耗时不高，但一旦裹在长事务里（比如前面做了大量插入、调用外部API、循环处理），它持有的锁就会卡住其他所有依赖这些行的操作。死锁往往不是查询慢，而是锁占太久。
实操底线：
- 把嵌套查询拆出来单独执行，只保留必要数据（比如只查ID列表），后续更新用
WHERE id IN (...)批量操作 - 禁止在事务中执行
SLEEP()、HTTP 请求、文件IO等非数据库操作 - 用
SELECT ... FOR UPDATE时，务必加WHERE条件且命中索引，否则会锁整张表（LOCK_MODE X LOCK_TYPE TABLE）
最常被忽略的一点：嵌套查询里的 ORDER BY + LIMIT 在 REPEATABLE READ 下可能触发间隙锁锁定“不存在的行”，看似没数据，其实锁了一大片空隙。检查执行计划里的 Extra 字段是否含 Using index condition; Using where; Using filesort —— 后两者往往是锁扩散的信号。
