嵌套查询常触发Nested Loops并暴增逻辑读，因其天然适配相关子查询语义：外层每行驱动一次内层扫描，导致重复I/O；若内表无索引，还引发CPU飙升。
为什么嵌套查询常触发Nested Loops并暴增逻辑读
因为相关子查询（correlated subquery）天然匹配Nested Loops的执行语义：外层每行都驱动一次内层扫描。数据库优化器一看子查询里有 t1.y = t2.x 这类依赖外层字段的条件，就大概率放弃哈希或合并连接，直接选Nested Loops——它不用预加载整个内表，内存开销小，但代价是重复I/O。
典型表现是：外层返回1万行，子查询每次扫5000行，总逻辑读就到5000万。这还不是最糟的——如果内表没索引，每次扫描都是全表，CPU也跟着飙高。
如何从执行计划确认是Nested Loops在作祟
关键看三点，缺一不可：
- 执行计划中存在
Nested Loops算子节点 - 该节点右侧子树里包含子查询（如
SELECT ... FROM t2 WHERE t2.x = t1.y） - 右侧没有
Table Spool（SQL Server）、Materialize（PostgreSQL）或TempTable（MySQL 8.0.23+）这类物化标记
如果右侧只有 Clustered Index Scan 或 Index Seek 但没物化，基本就是“重复计算”；若看到 EstimatedRows 是100、ActualRows 是10000，说明统计信息失效，优化器误判了驱动表大小。
哪些写法会强行锁死Nested Loops
不是所有子查询都会被优化器重写为JOIN，以下结构极易固化为Nested Loops：
-
WHERE col IN (SELECT ... FROM t2 WHERE t2.x = t1.y)：绝大多数场景下无法转半连接 -
SELECT (SELECT name FROM users u WHERE u.id = o.user_id) AS username FROM orders o：标量子查询，即使users.id有主键，也可能因参数嗅探失败而拒绝物化 - 子查询含
ORDER BY ... LIMIT 1但没加GROUP BY或显式TOP 1：优化器不敢缓存结果，怕语义不等价
这些写法看似简洁，实则把执行路径交给了优化器的保守策略——宁可多读，也不愿错。
改用JOIN也不一定安全：边界在哪
JOIN能绕过Nested Loops，但不是银弹。要注意三个硬约束：
- 若子查询本身含窗口函数（如
ROW_NUMBER() OVER (PARTITION BY x ORDER BY y)），强行JOIN会把排序下推到连接后，可能触发TempDB spill或磁盘排序 - 当子查询结果集极小（WITH cte AS (SELECT ...) 反而更稳——多数引擎会物化一次，后续直接读内存
- 若原查询用
EXISTS检查存在性，改LEFT JOIN ... ON ... WHERE right.col IS NULL后，必须确保JOIN条件字段允许NULL，否则语义已变
真正卡住性能的，往往不是语法本身，而是物化时机和统计信息是否跟得上数据变化。一个 UPDATE 后忘了 ANALYZE 或 UPDATE STATISTICS，就足以让原本跑得飞快的子查询慢十倍。
