存在Rebinds > 1的子查询节点即表明嵌套子查询被反复执行，是内存压力源头；需用SET STATISTICS PROFILE ON实际执行并检查Nested Loops内循环侧或Compute Scalar下的Rebinds值。
看执行计划里有没有 Rebinds > 1 的子查询节点
Rebinds 值大于 1 是嵌套子查询被反复执行的直接证据——比如外层 10 万行，Rebinds = 100000，说明内层逻辑被完整重跑 10 万次。这不是“可能慢”，而是内存压力源头。
操作上必须用 SET STATISTICS PROFILE ON（不是 XML），然后实际执行语句；光看图形化执行计划或 SET STATISTICS XML ON 容易漏掉 Rebinds 统计值。
- 在返回的文本结果中找
Rebinds列，重点关注出现在Nested Loops内循环侧、或Compute Scalar下方的子查询节点 - 若看到
EstimateRebinds="100000"且ActualRows接近该值，基本锁定问题语句 - 别信“这个子查询只查几个 ID”——只要它引用了外层列（如
WHERE status = o.status），就必然触发 Rebinds
检查是否出现 Table Spool (Eager) 或 Sort 节点大量物化
SQL Server 遇到无法下推谓词的嵌套结构时，会强制用 Table Spool (Eager) 把中间结果暂存内存，再供外层反复读取。一旦估算行数远超实际业务量（比如预估 50 万行，实际只有几百），就是物化失控信号。
执行 SET STATISTICS XML ON 后，在 XML 执行计划里搜索 RelOp PhysicalOp="Table Spool" 或 PhysicalOp="Sort"，重点看其 EstimatedRows 和 EstimateRebinds 属性。
- 多个连续
Table Spool (Eager)节点，尤其嵌套在Nested Loops内部，说明优化器已放弃谓词下推 -
Sort节点若没对应ORDER BY或TOP，大概率是为哈希匹配或去重强加的，纯属内存浪费 - 日志里若出现
Failed to allocate memory for sort或MEMORYCLERK_SQLQERESERVATIONS占比异常高，和这类节点强相关
用临时表显式物化最内层稳定子查询
三层以上嵌套（尤其含 GROUP BY 或 HAVING）时，SQL Server 2019 优化器常算不出最优路径——不是你写错，是它“算不过来”。此时硬调参数或改写 JOIN 效果有限，不如主动接管物化过程。
把最深那层不依赖外层的子查询拎出来，用 SELECT INTO #tmp 显式落地，并立刻建索引。这能彻底切断嵌套链，让后续 JOIN 行数可控、统计信息准确。
- 写法示例：
SELECT user_id INTO #active_users FROM users WHERE status = 'active'; CREATE CLUSTERED INDEX IX_user_id ON #active_users(user_id); - 之后主查询改用
JOIN #active_users au ON o.user_id = au.user_id，执行计划立即扁平 - 禁用
SELECT * INTO：必须明确字段列表，避免隐式类型转换拖慢插入和索引创建 - 别省略索引：哪怕只查
user_id，没索引的#tmp表 JOIN 时仍可能退化成扫描
确认 CTE 是否真被物化，还是仅逻辑重写
CTE 在 SQL Server 里本质是“命名子查询”，不保证物化。盲目用 CTE 拆嵌套，反而可能让优化器放弃谓词下推，导致更差的执行计划。
关键看 CTE 定义里有没有过滤条件和字段裁剪：如果 CTE 里写 SELECT * 或没 WHERE，外层再怎么加条件，优化器也可能全量物化整个 CTE 结果。
- 安全写法：每个 CTE 必须包含最终需要的字段 + 最小必要过滤，例如
WITH recent_orders AS (SELECT order_id, user_id FROM orders WHERE created_at > '2025-01-01') - 递归 CTE 必须带终止条件：
WHERE level ，并确认 <code>cte_max_recursion_depth已设为相同值（默认 100，建议 ≤ 20） - 验证是否物化：执行后查
sys.dm_exec_query_stats，对比 CTE 版本和等价临时表版本的total_logical_reads，差距大说明 CTE 未生效
真正危险的不是嵌套语法本身，而是优化器在多层嵌套下对中间结果规模的误判——它可能为 100 行预估分配 10 万行内存，又在运行时发现撑不住，只能 spill 到 TempDB 或直接 OOM。盯紧 Rebinds 和 Spool 节点，比反复重写 SQL 更快定位根因。
