直接查看实际执行计划中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 字段，而不是只看执行时间。缓存会让时间失真，但扫描行数不会骗人。