嵌套查询本身不导致死锁，但会因加锁顺序失控引发死锁；其根本原因是多个事务对同一组行以不同顺序加锁形成环形等待，而子查询物化、缺失索引、全表扫描等会加剧锁范围与顺序的不可预测性。
嵌套查询本身不导致死锁，但会让加锁顺序失控
死锁不是因为写了SELECT ... WHERE id IN (SELECT ...)就必然发生，而是多个事务在并发执行时，对同一组行以不同顺序加锁，形成环形等待。嵌套查询（尤其是IN、EXISTS或子查询驱动的UPDATE）会放大这种不确定性：优化器可能把子查询物化为临时表、提前加锁、或因缺失索引触发全表扫描+间隙锁——这些都让“哪几行被锁”“按什么顺序锁”变得不可预测。
常见错误现象：ERROR 1213 (40001): Deadlock found when trying to get lock频繁出现在含子查询的UPDATE语句中，且复现不稳定；SHOW ENGINE INNODB STATUS\G显示两个事务各自持有部分行锁，又互相等待对方释放。
- 检查子查询是否走索引：用
EXPLAIN FORMAT=JSON看key字段是否非NULL，rows_examined是否远小于表总行数 - 避免在子查询
WHERE里用函数、OR、类型隐式转换（如INT字段传字符串）——这些都会让索引失效 - MySQL 5.7+ 默认可能物化子查询，但若子查询没索引，仍会逐行加临键锁（Next-Key Lock），锁范围远超业务需要
用JOIN重写IN/EXISTS，强制统一加锁路径
把UPDATE t1 SET x=1 WHERE id IN (SELECT id FROM t2 WHERE status='pending')改成JOIN，不只是语法调整，是让优化器放弃物化路径、走嵌套循环，并显式控制关联顺序和锁粒度。
实操要点：
- 确保
JOIN条件字段都有索引：t1.id和t2.status必须分别有索引，复合索引(status, id)更优 - 写法示例：
UPDATE t1 JOIN t2 ON t1.id = t2.id SET t1.x = 1 WHERE t2.status = 'pending' - 如果
t2数据量大，加LIMIT 500分批更新，每批后COMMIT，避免单次锁住上万行 - 禁止在
JOIN中用DATE(created_at)这类计算字段做条件，会导致索引失效和锁升级
拆成两步：先查ID再更新，绕过子查询隐式锁
当JOIN改写不适用（比如子查询含聚合、窗口函数或跨库查询），最稳妥的方式是把嵌套逻辑拆到应用层：先执行窄查询拿到主键列表，再拼IN批量更新。这能彻底规避子查询物化与锁扩散风险。
关键约束：
- 第一步
SELECT id FROM t2 WHERE ...必须带ORDER BY id（或唯一索引列），确保所有事务按相同顺序获取ID，收敛加锁路径 - 第二步
UPDATE t1 SET ... WHERE id IN (1,2,3...)的ID列表长度别超max_allowed_packet，超长需分批 - MySQL 8.0+ 支持子查询内
ORDER BY + LIMIT生效，低版本必须用临时表或应用层排序 - 不要在两步之间插入业务逻辑或网络调用——否则事务时间拉长，死锁概率反升
隔离级别和索引缺一不可
READ COMMITTED能减少间隙锁，但不能替代索引；有索引却用错隔离级别，照样锁表。二者必须配合使用。
具体操作：
- 对OLTP场景，显式设
SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED，让InnoDB只锁实际命中的行，不加间隙锁 - 所有出现在
WHERE、JOIN、ORDER BY中的字段，只要并发DML频繁，就必须建索引；复合索引注意最左前缀匹配 - 用
EXPLAIN FORMAT=JSON确认using_index_condition为true，且type是range或ref，不是ALL或index - 绝对不要在嵌套查询里混用
ORDER BY created_at LIMIT 1——若created_at无索引，可能全表扫描并锁住所有扫描过的间隙
真正难处理的是多表关联更新时的隐式锁顺序，以及分页批量操作中未显式排序的ID列表——这些细节不盯紧，索引和隔离级别都白配。
