子查询在执行计划中“消失”是因为SQL Server优化器默认将其内联展开，合并进主查询树；这是正常优化行为，旨在提升性能，但可能掩盖子查询自身的性能问题。
为什么子查询在执行计划里“消失”了？
SQL Server 查询优化器默认会对独立子查询（如 SELECT ... WHERE col > (SELECT AVG(...) FROM t)）做自动内联展开，也就是把子查询逻辑合并进主查询树。结果就是你在图形化执行计划里看不到单独的子查询分支，只有聚合、连接或扫描等统一操作符。这不是 bug，是优化行为——但会掩盖子查询本身的性能问题，比如它是否被多次执行、是否用了合适索引。
OPTION (RECOMPILE) 不能强制展开，但能暴露真实行为
加 OPTION (RECOMPILE) 不会让子查询“显形”，但它能绕过参数嗅探缓存，让优化器每次重新编译，从而更可能生成反映子查询实际代价的计划（例如，把原本被内联的标量子查询转为嵌套循环+索引查找）。尤其当子查询涉及变量或参数时，这个提示常让执行计划从“看似高效”变成“暴露出 key lookup 或重复扫描”。
- 适用场景：子查询结果依赖运行时参数，且你怀疑缓存计划误导了优化器判断
- 注意点：
RECOMPILE增加编译开销，别滥用在高频小查询上 - 验证方式：对比加/不加该提示后，
Actual Number of Rows在子查询对应算子（如Compute Scalar或Stream Aggregate）上的差异
用 FORCE ORDER 或 LOOP JOIN 间接控制子查询物化时机
当子查询被当作派生表（FROM (SELECT ...) AS x）或 CTE 时，优化器有时会延迟计算或重排执行顺序。加 OPTION (FORCE ORDER) 可强制按 SQL 书写的顺序执行，让子查询先物化成临时结果集；而 OPTION (LOOP JOIN) 在含 JOIN 的子查询场景下，可能阻止哈希/合并连接把子查询逻辑“吞掉”，从而在计划中保留其独立扫描路径。
- 典型触发条件：子查询返回少量行，但基表很大，你希望它先过滤再连接
- 风险：硬编码连接策略可能在数据分布变化后变差，需配合
STATISTICS IO验证逻辑读是否下降 - 不要对
WHERE EXISTS (SELECT ...)直接加LOOP JOIN，它本身已倾向嵌套循环，加了反而可能抑制优化器选择更优路径
真正想看子查询独立执行计划？改写为临时表或变量
如果目标纯粹是“分析子查询自身性能”，最可靠的方式是把它拆出来单独跑——用 SELECT ... INTO #temp 或 INSERT INTO @table_var 显式物化，再查执行计划。这样你能清楚看到：它用了什么索引、是否发生隐式转换、统计信息是否过期。
- 示例：
SELECT AVG(Freight) INTO #avg FROM Orders;→ 单独看这句的执行计划 - 注意：
#temp表有统计信息（SQL Server 2014+ 自动创建），而@table_var没有，后者计划更可能退化为估计行数 1 - 关键提醒：临时表方案只适用于调试，上线代码里频繁用
SELECT INTO会带来 tempdb 压力和事务日志膨胀
子查询是否展开，本质是优化器对代价的权衡，不是开关能直接控制的行为。真正要抓的问题，往往藏在“它本该展开却没走索引”或“它被内联后放大了低效操作”里——盯着 Estimated Subtree Cost 和实际行数偏差，比执着于让子查询在计划里“露脸”更有价值。
