SQL Server中子查询在执行计划中不显式标注，而是体现为Nested Loops、Compute Scalar或Apply算子；右键查看Estimated Number of Executions（远大于1即相关子查询反复执行）、Actual vs Estimated Rows偏差及Warnings可精准定位性能瓶颈。
怎么看子查询在执行计划里藏哪儿了
SQL Server 的图形化执行计划不会单独标出“子查询”字样，它把子查询展开成实际操作节点。重点盯住 Nested Loops、Compute Scalar、Apply（尤其是 Left Apply 和 Inner Apply）这几类算子——它们几乎就是子查询的物理化身。比如一个 WHERE col IN (SELECT ...) 很可能转成 Left Apply；而 SELECT (SELECT ...) FROM t 标量子查询则常表现为 Compute Scalar 套着一个嵌套的 Nested Loops。
子查询节点右键能看到什么关键信息
鼠标悬停或右键点击疑似子查询的节点（尤其是带箭头指向内部的 Apply 或 Nested Loops），弹出属性窗口后重点关注：
-
Estimated Number of Executions：如果远大于 1（比如上万次），说明该子查询被外层每一行反复执行——这是典型的“相关子查询灾难” -
Estimated I/O Cost和Estimated CPU Cost：加起来占整个计划 30% 以上，就得优先处理 -
Actual Number of Rows（启用实际执行计划后可见）：若远高于Estimated Number of Rows，说明统计信息过时，子查询基数预估严重失准 -
Warnings栏：出现 “No Join Predicate” 或 “Convert Issue” 提示，往往意味着隐式转换导致子查询无法走索引
哪些子查询模式最容易拖慢整体查询
不是所有子查询都危险，但以下几种在 SQL Server 2017 中特别容易失控：
-
SELECT * FROM t1 WHERE col IN (SELECT col FROM t2 WHERE t2.id = t1.id)：外层每行触发一次内层扫描，Estimated Number of Executions等于t1行数 -
SELECT (SELECT MAX(x) FROM t2 WHERE t2.ref = t1.id) AS max_val FROM t1：标量子查询 + 聚合，即使t2.ref有索引，也常因缺少覆盖列触发Key Lookup - 含
OR或函数的子查询条件，如WHERE name LIKE '%' + @input + '%'：直接让子查询部分放弃使用任何索引 - 子查询里用了
TOP但没配ORDER BY：SQL Server 2017 可能生成非确定性执行路径，优化器难以准确估算成本
改写子查询前先确认统计信息是否新鲜
很多“慢子查询”其实是假象——因为统计信息陈旧，优化器误判子查询代价低，结果选了嵌套循环而非哈希匹配。在动手重写前，务必运行：
UPDATE STATISTICS t2 WITH FULLSCAN;
尤其当子查询涉及的表 t2 近期有大量增删改。另外注意：sp_updatestats 默认跳过小表和空表，对子查询依赖的小维度表无效，必须显式指定。
子查询性能问题最棘手的地方在于：它不总在语句表面暴露。同一段 SQL，在不同数据分布下，可能从 Hash Match 退化为几千次 Nested Loops，而图形化计划只告诉你“发生了”，不告诉你“为什么突然发生”。盯着 Estimated Number of Executions 和实际行数偏差，比死磕语法结构更可靠。
