子查询在执行计划中“消失”是因为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 和实际行数偏差，比执着于让子查询在计划里“露脸”更有价值。