怎样在SQL Server 2019中排查聚合查询导致的CPU飙升？-SQL-PHP中文网

sql server 2019聚合查询高cpu主因是执行路径低效：未启用批模式、逻辑读过高、统计信息过期或参数敏感计划导致。需检查兼容级别≥150、batchmode="true"、logical_reads是否异常、统计信息更新及时性及psp影响。

怎样在sql server 2019中排查聚合查询导致的cpu飙升？

聚合查询（GROUP BY、SUM、COUNT、AVG 等）在 SQL Server 2019 中一旦数据量变大或计划失准，极易引发 CPU 持续 90%+，但问题往往不在于“用了聚合”，而在于执行路径是否被迫走低效模式。

看执行计划是否走了行模式而非批模式

SQL Server 2019 对聚合类操作做了关键优化：只要满足条件，会自动启用批模式（batch mode），大幅降低 CPU 开销。但这个优化有前提——不是所有表都能触发。

列存储索引（CLUSTERED COLUMNSTORE INDEX）上默认启用批模式，聚合性能通常很好
行存储表（heap 或 CLUSTERED INDEX）上，只有开启 batch mode on rowstore 功能才可能用上批模式；需确认数据库兼容级别 ≥ 150（SQL Server 2019 默认是 150，但升级后可能仍为旧值）
检查方法：在 SSMS 中执行 SET STATISTICS XML ON 后运行聚合语句，查看执行计划中运算符属性是否有 BatchMode="true"；若全是 BatchMode="false"，说明没走批模式
若未启用，可临时测试：执行 ALTER DATABASE CURRENT SET COMPATIBILITY_LEVEL = 150（注意影响面），再重查计划

查逻辑读是否异常高，暴露扫描范围失控

聚合本身不耗 CPU，耗的是遍历和计算每一行的过程。如果 logical_reads 高得离谱（比如千万级），说明它正在全表扫或索引扫，而不是走窄路径。

运行以下语句快速定位当前高 CPU 聚合会话：

SELECT TOP 5
    r.session_id,
    r.cpu_time,
    r.logical_reads,
    r.total_elapsed_time,
    t.text AS query_text
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
WHERE r.status = 'running'
ORDER BY r.cpu_time DESC;

重点看 logical_reads 和 cpu_time 是否同步飙升（比如 logical_reads > 500 万且 cpu_time > 30 秒）
若存在，说明聚合没走索引下推（index seek + stream aggregate），而是被迫做哈希/排序聚合（Hash Match Aggregate 或 Sort + Stream Aggregate），尤其当 GROUP BY 字段无索引时几乎必然发生

确认统计信息是否过期，导致优化器选错算法

聚合查询对基数估算极度敏感。过时的统计信息会让优化器误判数据分布，比如把“只返回 10 行”的 GROUP BY 估算成“返回 10 万行”，从而放弃索引 seek，改用哈希聚合——后者在内存不足时还会 spill 到 tempdb，进一步拖慢并吃 CPU。

检查关键表统计信息最后更新时间：

SELECT 
    s.name AS stats_name,
    s.auto_created,
    s.user_created,
    STATS_DATE(o.object_id, s.stats_id) AS last_updated
FROM sys.stats s
JOIN sys.objects o ON s.object_id = o.object_id
WHERE o.name = 'YourTableName';

若 last_updated 是几周前，或表数据变动 > 20%，立即更新：UPDATE STATISTICS YourTableName WITH FULLSCAN, NORECOMPUTE（生产环境慎用 FULLSCAN，可用 SAMPLE 30 PERCENT 替代）
特别注意：含 WHERE 条件的聚合（如 SELECT COUNT(*) FROM t WHERE status = 'A' GROUP BY category），要确保 status 和 category 的联合统计信息存在，否则优化器无法准确估算分组数

警惕参数敏感计划（PSP）在聚合场景下的放大效应

聚合查询常被封装在存储过程中，用参数控制过滤条件。一旦首次执行时传入一个“选择性极差”的参数（如 @status = 'ALL'），SQL Server 可能缓存一个为全量数据设计的哈希聚合计划——后续即使传入 @status = 'ERROR'（只 3 行），也会复用该计划，白白做大量无效哈希计算，CPU 白烧。

识别方式：同一存储过程不同参数下，sys.dm_exec_query_stats 中的 avg_cpu_cost 差异巨大，但 plan_handle 相同
验证是否 PSP：用 sys.dm_exec_cached_plans 关联 sys.dm_exec_query_plan 查看计划中是否存在 ParameterCompiledValue 与实际运行值明显不符
缓解手段（按侵入性升序）：
- 加 OPTION (RECOMPILE)（适合执行频次低、参数变化大的场景）
- 拆分逻辑，为高频参数值单独写分支（如 IF @status = 'ERROR' ... ELSE ...）
- 升级到 SQL Server 2022 启用 QUERY_STORE 的自动计划修正（SQL Server 2019 不支持）