直接查看实际执行计划中PhysicalOp="Table Spool"或" Eager Spool"节点，即表明子查询被物化；其上游若为NOEXPAND提示或含外层列引用的子查询，且下游EstimateRows陡增，则确认为子查询触发的spool。
SQL Server里怎么确认子查询触发了Table Spool？
直接看实际执行计划，找 PhysicalOp="Table Spool" 或 PhysicalOp="Eager Spool" 节点——它们就是NOEXPAND提示或优化器主动物化子查询的结果。这类节点不是凭空出现的，基本都对应一个显式或隐式的子查询（尤其是带 NOEXPAND 的索引视图引用，或优化器为避免重复计算而强制缓存中间结果）。
注意：Table Spool 本身不报错，但会把数据先写入 tempdb 再读回，IO 和内存开销陡增；如果 spool 节点上游 EstimateRows 很小、下游却突然放大几十倍，大概率是子查询被反复展开又物化，形成“假聚合”假象。
MySQL/PostgreSQL里没有Spool，但有类似症状怎么办？
MySQL 不生成 Spool 操作，但遇到相关子查询时，EXPLAIN 里会明确标出 DEPENDENT SUBQUERY；PostgreSQL 则显示为嵌套循环中反复调用的 SubPlan 或 InitPlan。这两种情况本质和 SQL Server 的 Spool 类似：都是为每行外层数据重跑一次内层逻辑，只不过实现机制不同——MySQL 建临时表，PostgreSQL 多次执行子计划，SQL Server 物化到 spool 缓冲区。
排查要点：
-
EXPLAIN中rows列远大于最终结果行数（比如外层 10 万行，子查询rows=800000），说明存在严重嵌套放大 - 子查询
type是ALL或index，且Extra含Using temporary; Using filesort，说明没走索引还建了临时结构 - 子查询 WHERE 条件字段缺失联合索引（例如
WHERE user_id = ? AND status = 'error'，但只有user_id单列索引）
标量子查询（SELECT 列里嵌套）为什么最容易出 Spool 类问题？
因为数据库引擎几乎只能用嵌套循环处理它：对主表每一行，都得单独执行一次子查询。哪怕子查询只返回一个 COUNT，只要它依赖外层字段（如 (SELECT COUNT(*) FROM logs WHERE user_id = u.id)），就无法提前聚合，也无法下推过滤条件。
真正有效的解法不是加索引，而是改写结构：
- 把子查询提前聚合：先
SELECT user_id, COUNT(*) AS cnt FROM logs GROUP BY user_id，再LEFT JOIN回主表 - 如果只是判断“是否存在”，一律换
EXISTS，它能短路退出，不会扫完整张子表 - 若聚合量太大（比如日志表上亿行），必须加时间范围约束（如
WHERE create_time > '2026-08-27'）再聚合，否则提前物化也扛不住
IN/EXISTS 改 JOIN 时，哪些坑会导致性能更差？
不是所有子查询都能安全 JOIN，漏掉任一硬约束就会引入错误或新瓶颈：
- 子查询结果含
NULL时，NOT IN会整个失效——必须用LEFT JOIN ... WHERE right.id IS NULL，且显式加AND right.id IS NOT NULL过滤 NULL - 主表与子表是一对多（如用户→订单），直接
INNER JOIN会让主表行数膨胀——要么加DISTINCT，要么退回到EXISTS - 子查询带
ORDER BY + LIMIT 1（如取每个用户的最新订单），不能直接 JOIN——得先用派生表或窗口函数算出最新记录，再关联
最易被忽略的是：改写后必须对比 EXPLAIN 的 rows 和 Extra 字段，而不是只看执行时间。缓存会让时间失真，但扫描行数不会骗人。
