嵌套查询不加锁但导致加锁顺序不可控，易引发死锁；IN/EXISTS子查询在MySQL 5.7+默认物化临时表，可能全表扫描加临键锁、回表顺序混乱；ORDER BY + LIMIT子查询若无索引仍全表加锁；JOIN重写可统一加锁路径但依赖索引和语义一致性；READ COMMITTED缩小锁粒度却不解决顺序问题；根本难点在于子查询执行时机与优化器决策的隐式耦合。

嵌套查询本身不加锁，但会让加锁顺序变得不可控——这是并发下死锁频发的根源。

IN/EXISTS 子查询触发物化临时表，提前锁定不确定行

MySQL 5.7+ 默认启用 materialization，子查询如 SELECT id FROM t2 WHERE status = 'pending' 会被物化成临时表。这个过程可能： - 全表扫描（status 无索引时），对所有候选行加临键锁 - 物化后逐行回表关联，导致外层 UPDATE t1 按临时表顺序而非主键顺序加锁 - 事务 A 按 t2 表聚簇索引顺序锁了 t2.id=100 → 再锁 t1.id=200；事务 B 却先锁了 t1.id=200 → 再查 t2 并锁 t2.id=100，形成循环等待

ORDER BY + LIMIT 在子查询里等于主动放弃索引控制

写 WHERE id IN (SELECT id FROM t2 ORDER BY created_at DESC LIMIT 10) 看似只取 10 行，实际风险极高： - 若 created_at 没索引，优化器放弃走索引，改用物化全表再排序 - 整张 t2 的候选行都被加锁，且锁顺序随机 - MySQL 8.0+ 虽对含 LIMIT 的子查询自动禁用物化，但前提是外层没 FOR UPDATE 或显式事务包裹，否则仍 fallback 到物化路径

JOIN 重写能强制统一加锁路径，但有前提条件

把 UPDATE t1 SET x=1 WHERE id IN (SELECT id FROM t2 WHERE flag=1) 改成 UPDATE t1 JOIN t2 ON t1.id = t2.id SET t1.x = 1 WHERE t2.flag = 1，效果取决于： - t2.flag 必须有索引，否则驱动表 t2 仍全表扫描加锁 - t1.id 必须是主键或唯一索引，否则 JOIN 后回表可能引发额外间隙锁 - 若业务逻辑依赖子查询的快照语义（如多次读取中间结果），JOIN 会改变执行时机，可能暴露不可重复读

READ COMMITTED 隔离级别能缩小锁范围，但不解决顺序问题

在 REPEATABLE READ 下，WHERE status = 'pending' 若没索引，InnoDB 会对整个索引区间加间隙锁；切换到 READ COMMITTED 后： - 只锁实际命中的行，不加间隙锁，锁粒度变小 - 但子查询仍可能被物化，加锁顺序依然不受控 - 必须显式设置：SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED，且仅对当前会话生效 - 若业务依赖 RR 的一致性快照（比如报表任务中多步聚合依赖同一快照），降级会导致逻辑错乱

真正难处理的不是语法怎么写，而是子查询执行时机和优化器决策之间的耦合——它藏在 EXPLAIN 看不见的地方，却在并发高峰时突然爆发。