子查询慢主因是逻辑读暴增，如外层100行致子查询重复执行100次、总逻辑读达50万；判断是否重复计算需查执行计划中子查询是否位于Nested Loops右侧且未物化。
子查询为什么慢？先看逻辑读暴增的典型表现
嵌套子查询慢，往往不是语法问题，而是执行计划里 logical reads 高得离谱——比如外层 100 行，子查询被重复执行 100 次，每次扫 5000 行，总逻辑读就到 50 万。SQL Server 的 SET STATISTICS IO ON 能立刻暴露这点，Oracle 则看 v$sql 中的 buffer_gets。MySQL 8.0+ 可用 EXPLAIN FORMAT=JSON 查 "rows_examined_per_scan" 和实际扫描次数。
如何判断子查询是否被“重复计算”
关键看执行计划中子查询是否出现在内层循环（Nested Loops）的右侧，且没有被物化（如 SQL Server 的 Table Spool，PostgreSQL 的 Materialize 节点）。常见陷阱：
- WHERE 中写
col IN (SELECT ... FROM t2 WHERE t2.x = t1.y)：绝大多数情况下触发相关子查询，t1 每行都重跑一次 t2 扫描 - SELECT 列表里放标量子查询，如
(SELECT name FROM users u WHERE u.id = o.user_id)：即使加了索引，仍可能因缺少统计信息或参数嗅探失效，导致计划选择嵌套循环而非哈希匹配 - 子查询含聚合但没加
GROUP BY或TOP 1，优化器不敢物化，宁可反复算
替代方案：用 JOIN 或 CTE 替代时的性能边界
不是所有子查询都该改，要看数据分布和复用性：
- 若子查询结果集小（WITH cte AS (...) ——多数引擎会物化一次，后续直接读缓存
- 若外层大表与子查询表有高选择性关联字段（如主键/唯一索引），强制改
JOIN通常能触发哈希连接或合并连接，逻辑读下降 70%+ - 但若子查询本身含复杂窗口函数或
ORDER BY ... LIMIT 1，强行 JOIN 可能引发排序溢出（TempDB spill或disk-based sort），此时保持子查询 + 加覆盖索引反而更稳
监控物理读突增，往往暴露缓存失效或执行计划退化
physical reads 骤升常意味着计划变了，或者缓冲池被刷空。重点查三件事：
- 对比两次执行的
query_plan_hash（SQL Server）或sql_id+plan_hash_value（Oracle）是否一致 - 检查子查询涉及的表是否近期发生大量
UPDATE/DELETE，导致统计信息过期，优化器误判行数，选错驱动表 - 确认子查询中是否用了本地变量（如
@min_date），触发参数敏感计划，而缓存中只有针对某值的低效计划
物理读高但逻辑读不高，大概率是数据不在内存；两者都高，基本锁定是计划缺陷或索引缺失。别急着加内存，先看执行计划里子查询节点的 EstimatedRows 和 ActualRows 是否差一个数量级。
