非并行查询：执行计划节点CPU时间总和与STATISTICS TIME结果差异原因
2026-6-25
非并行查询中CPU时间统计差异的原因及对比有效性分析
一、核心差异的原因
- 统计范围不一致：
SET STATISTICS TIME统计的是查询从提交到完成的全生命周期CPU消耗，包含查询解析、编译、绑定、执行计划缓存查找，以及执行阶段之外的系统辅助开销；而执行计划节点的CPU时间仅统计执行阶段内各算子的CPU消耗，不覆盖解析、编译等前置环节。 - 计时精度与取整规则差异：SQL Server的CPU时间统计以毫秒为展示单位，但内部计时粒度更细。
SET STATISTICS TIME的结果是取整后的值，而执行计划节点的时间是更细粒度的累加值，两者的取整逻辑不同会导致汇总后出现偏差。 - 未被捕获的后台开销：执行过程中诸如内存分配/释放、少量日志记录等后台操作的CPU消耗，会被计入
SET STATISTICS TIME的总CPU时间，但不会被执行计划的算子节点统计捕获。
二、对比的有效性分析
这种直接对比不具备严格有效性，原因如下：
- 两者统计维度完全不同：一个是端到端的全流程CPU开销，一个仅覆盖执行阶段的算子CPU开销，统计范围无完全重叠性，直接相加对比没有参考意义。
- 轻量查询的偏差被放大：像示例中的简单查询，解析、编译等前置环节的CPU占比相对执行阶段更高，两者的差异会更明显。
三、示例说明
执行的查询：
select name from sys.tables;
SET STATISTICS TIME返回结果：
SQL Server 执行时间:
CPU 时间 = 4 毫秒， 占用时间 = 2 毫秒。
总执行时间: 00:00:00.053
执行计划节点CPU时间汇总：
从执行计划的RunTimeInformation中汇总所有节点CPU时间，结果为9毫秒。
内容的提问来源于stack exchange，提问作者Arun Prasanth
相关产品推荐
相关产品推荐
