在SSMS中查看子查询执行计划需按Ctrl+M启用“包括实际执行计划”后执行查询，重点识别Compute Scalar（标量子查询）、Apply算子（相关子查询）及重复索引操作，结合XML计划中的ActualExecutions与EstimateExecutions比对判断性能问题。
怎么在 SSMS 里看到子查询的执行计划
SQL Server 不会把子查询单独标成“子查询节点”，它会在执行计划里把子查询内联展开或转成嵌套操作符（比如 Nested Loops、Compute Scalar、Apply），所以不能靠名字找，得看结构。
打开 SSMS，写好含子查询的语句（比如带 (SELECT MAX(...)) 的 SELECT），然后按 Ctrl+M 启用「包括实际执行计划」，再执行。执行完成后，下方标签页会显示图形化计划——重点不是找“子查询”字样，而是看有没有以下特征：
-
Compute Scalar节点：常见于标量子查询（如SELECT ..., (SELECT ...) AS col），它表示 SQL Server 把子查询结果计算后作为一列输出 -
Apply算子（INNER APPLY或OUTER APPLY）：当子查询引用外部表字段（如WHERE t1.id = t2.ref_id）时，优化器常把它转成Apply，此时子查询逻辑就体现在右侧输入分支里 - 重复出现的
Index Seek或Clustered Index Scan：如果子查询没被物化或缓存，且外部主查询返回 N 行，该子查询可能被反复执行 N 次——这时你会看到同一个索引操作在计划里高频出现，且其「实际行数」和外部行数一致
标量子查询 vs. 相关子查询在执行计划里的区别
关键看子查询是否依赖外部行值。不依赖（如 (SELECT COUNT(*) FROM Orders)）是标量，通常只执行一次；依赖（如 (SELECT TOP 1 Price FROM OrderDetails od WHERE od.OrderID = o.OrderID)）是相关子查询，必须逐行求值。
这种差异直接反映在执行计划中：
- 标量子查询：大概率出现在
Compute Scalar下方，且其子树只执行 1 次（「实际执行次数」= 1） - 相关子查询：大概率触发
Apply算子，右侧分支的「实际执行次数」等于左侧驱动表的行数；若右侧用了Index Seek，说明有合适索引；若出现Clustered Index Scan，说明每次都在全扫 OrderDetails 表——这就是性能杀手 - 注意
Estimated Number of Executions和Actual Number of Executions字段：二者严重不匹配（比如预估 1 次、实际 5000 次）就是相关子查询失控的明确信号
用 SET STATISTICS XML ON 定位子查询慢在哪
图形化计划有时不够细，尤其想确认某节点是否真在反复执行，就得看 XML 执行计划里的原始统计。
在查询前加：
SET STATISTICS XML ON; -- 你的含子查询的 SQL SET STATISTICS XML OFF;
执行后点击结果面板中的 XML 链接，搜索关键词：
-
<RelOp NodeId="X" PhysicalOp="Compute Scalar"：找到标量子查询对应节点，检查EstimateRows和ActualRows是否接近，差距大说明基数估算失准 -
<RelOp NodeId="Y" PhysicalOp="Nested Loops"或<RelOp NodeId="Z" PhysicalOp="Apply"：这是相关子查询的载体，重点看其EstimateExecutions和ActualExecutions——后者远大于 1 就坐实了“每行都跑一遍” - 查
<IndexScan或<IndexSeek的Table="@your_table"和SeekPredicates：确认 WHERE 条件是否真的能走索引；如果SeekPredicates为空，却写了WHERE col = @param，说明参数化失败或数据类型隐式转换导致索引失效
为什么有些子查询快、有些慢？关键看这三点
子查询本身不是原罪，慢是因为它放大了低效操作。真正决定快慢的是三件事：
- 驱动行数：外部查询返回 10 行，子查询最多执行 10 次；若返回 10 万行，子查询就算每次只要 1ms，总耗时也逼近 100 秒
- 子查询内是否可走索引：相关子查询里
WHERE条件字段没索引，或存在函数/类型转换（如WHERE YEAR(OrderDate) = 2022），就会强制扫描 - 是否被优化器重写为 JOIN：SQL Server 会尝试把部分子查询自动转成等价 JOIN，但仅限简单场景（如单表、无聚合、无 TOP）；一旦含
MAX()、COUNT(*)、TOP 1或多层嵌套，就大概率保留为 Apply，失去 JOIN 的批量处理优势
最易被忽略的是：你以为自己写的是“一次子查询”，但执行计划告诉你它被调用了几千次——这时候改写为 JOIN 或用 CTE 预计算，往往比调优子查询本身更有效。
