必须用 SET STATISTICS XML ON 查 ActualCPUms 定位深层子查询 CPU 瓶颈，SQL Server 2016+ 默认支持，旧版需跟踪标志 7412；结合 sys.dm_exec_query_stats 筛选高平均 CPU 语句，再针对性分析 XML 中 RelOp 节点的 ActualCPUms，并验证是否真为 CPU 密集型（cpu_time 占比超 80% 或 wait_type = 'SOS_SCHEDULER_YIELD'）。
直接看 ActualCPUms：必须用 SET STATISTICS XML ON
深层嵌套子查询的 CPU 消耗不会在普通执行计划里暴露——SET STATISTICS PROFILE ON 只给 EstimatedCPU 和总耗时，不拆解每个子查询节点的实际 CPU。真正能定位到“哪一层子查询吃 CPU”的，只有 SET STATISTICS XML ON 输出里的 ActualCPUms 字段。
实操要点：
- 必须在 SQL Server 2016 或更新版本（含 Express）上运行，旧版默认不收集该值；SQL Server 2014 及更早需手动启用跟踪标志
7412，风险高、不推荐 - 执行后别只扫“结果”面板，要切到“消息”面板，点开那个蓝色的 XML 链接
- 在打开的 XML 中搜索
<RelOp>节点，每个节点代表一个物理算子；嵌套越深，Nested Loops或Apply类型节点层级越靠内，其ActualCPUms值就是该子查询实际消耗的 CPU 毫秒数 - 注意：多个
ActualCPUms加总 ≈ 整条语句的cpu_time（来自sys.dm_exec_requests），但会略小——差值是调度开销，不是子查询漏算
用 sys.dm_exec_query_stats 查历史平均：避免每次手动跑 XML
开发或测试环境可以反复执行 XML，但生产环境不能随便开 STATISTICS XML（它会强制重编译、增加 CPU 开销）。这时得依赖缓存的聚合指标。
关键逻辑：嵌套子查询会被编译进整个批处理的执行计划，它的 CPU 消耗已计入 total_worker_time。你要做的是把“含深层子查询”的语句从缓存里筛出来，并按平均单次 CPU 排序：
- 先用
sys.dm_exec_query_stats+sys.dm_exec_sql_text找出total_worker_time / execution_count最高的前 50 条 - 在
text字段里 grepSELECT.*SELECT.*SELECT或FROM.*\(.+SELECT等模式，快速识别疑似多层嵌套的语句 - 对命中语句，再针对性地开
STATISTICS XML精确定位——别全量扫，否则 DMV 查询本身也占资源 - 注意：如果语句用了参数化（如
sp_executesql），sql_handle相同但文本被抽象了，此时得结合query_hash关联sys.query_store_query查原始文本
别被 logical_reads 或 elapsed_time 带偏：CPU 密集 ≠ I/O 密集
常见误区是看到某条嵌套查询 logical_reads 很低、elapsed_time 却很高，就断定“是 CPU 问题”。错——它可能卡在锁等待、网络延迟，甚至客户端没取完结果。
- 确认是否真为 CPU 密集：查
sys.dm_exec_requests，看status = 'RUNNABLE'且wait_type = 'SOS_SCHEDULER_YIELD'，这才是线程在等 CPU 时间片 - 对比
cpu_time和total_elapsed_time：若前者占后者 80% 以上，才大概率是纯计算瓶颈；若cpu_time很小但elapsed_time大，优先查wait_type（比如LCK_M_S、ASYNC_NETWORK_IO） - 嵌套子查询容易触发重复计算（如相关子查询在外部行循环中反复执行），这时
ActualCPUms在Compute Scalar或Apply节点会异常高，且该节点ActualRows明显大于 1——这是最典型的信号
真实场景下最容易忽略的一点
即使你拿到了每层子查询的 ActualCPUms，也不能直接说“优化第 3 层就能降 70% CPU”。因为 SQL Server 的优化器可能已将部分嵌套展开为连接，XML 里的节点层级不完全对应源 SQL 的缩进结构；同一逻辑子查询，在不同参数下可能走不同路径，ActualCPUms 波动极大。真正可靠的判断依据，是连续 3 次以上在相同数据分布、相似参数下捕获的 XML 中，某个节点的 ActualCPUms 始终稳定占比超 40%——这时才值得重写那一段逻辑。
