SQL Server 2022 中 GROUP BY 性能问题主因是执行计划走歪，90% 可通过索引顺序、WHERE 前置和避免函数包裹解决；剩余 10% 需评估是否改用预聚合或 DISTINCT。
GROUP BY 在 SQL Server 2022 中慢，往往不是语法写错了，而是执行路径走歪了——它默认会尝试排序或哈希分组，一旦数据量稍大、索引没对上、或者字段基数高，就立刻掉进磁盘临时表（Using temporary; Using filesort）的坑里。
直接结论：90% 的 GROUP BY 性能问题，靠「索引顺序 + WHERE 前置 + 避免函数包裹」就能解决；剩下 10% 要看是否真需要实时分组，还是该用预聚合或 DISTINCT 替代。
为什么加了索引，GROUP BY 还慢？
索引建了但没被有效利用，常见原因有：
-
GROUP BY字段顺序和索引列顺序不一致（比如索引是(status, dept_id)，却写GROUP BY dept_id, status） -
WHERE条件字段没前置到索引里（如WHERE region = 'CN' GROUP BY user_id，但索引只有(user_id)） - 在分组字段上用了函数，比如
GROUP BY YEAR(create_time)—— 索引完全失效 - 分组字段是
TEXT、XML或未加INCLUDE的大字段，导致回表严重
验证方式：执行 SET STATISTICS XML ON，看执行计划里 GROUP BY 节点是否出现 Hash Match 或 Sort，且 Estimated Row Count 远高于实际过滤后行数，说明分组前没过滤干净。
GROUP BY 索引怎么建才真正生效？
核心原则是：让索引同时覆盖 WHERE 过滤 + GROUP BY + SELECT 中的聚合字段（即覆盖索引）。
- 单字段分组：索引直接建在该字段上，如
GROUP BY product_id→CREATE NONCLUSTERED INDEX IX_sales_product_id ON sales(product_id) - 多字段分组：按「筛选性强 → 分组粒度粗」顺序排，例如
GROUP BY region, category，若region只有 5 个值而category有 500 个，则索引应为(region, category) - 带聚合字段：如
SELECT region, AVG(price) FROM sales GROUP BY region，建议建(region) INCLUDE (price)，避免回表读取price - 带
WHERE条件：如WHERE is_active = 1 GROUP BY region，索引必须是(is_active, region)，不能只建(region)
GROUP BY 能不能用 DISTINCT 替代？
能，而且有时快得多——尤其当你只关心“有哪些分组值”，不涉及聚合计算（如 COUNT(*)、SUM()）时。
- 场景示例：
SELECT app_account FROM logs WHERE dt >= '2026-08-01' GROUP BY app_account和SELECT DISTINCT app_account FROM logs WHERE dt >= '2026-08-01'逻辑等价，但后者常快 5–10 倍 - 原因：
DISTINCT可以用流式去重（Stream Aggregate），而GROUP BY默认触发完整分组流程，即使没聚合函数也绕不开 - 注意：
DISTINCT不能替代带聚合的GROUP BY，比如COUNT(*)或MAX(created_at)必须用GROUP BY
SQL Server 2022 自动调优能帮上忙吗？
能，但别全信。它的 CREATE_INDEX 功能确实会基于执行统计推荐索引，但推荐结果常忽略业务语义。
- 它可能给高频
GROUP BY user_id建索引，却漏掉更关键的WHERE status = 'paid' AND created_date > ...组合条件 - 自动创建的索引未必包含
INCLUDE字段，仍需手动补全 - 建议开启后，定期查
sys.dm_db_tuning_recommendations，再人工校验：推荐索引是否覆盖了你的WHERE + GROUP BY + SELECT全路径 - 对高基数字段（如
app_account有 5000+ 唯一值），自动调优可能误判为“值得建索引”，实则应先归类降维（如按前两位 hash 分桶）
最易被忽略的一点：SQL Server 2022 的 work_mem 类似参数叫 max server memory 和查询内存授予（query_memory_grant），但真正影响 GROUP BY 内存使用的是 cost threshold for parallelism 和 min memory per query——这些不调，光建索引也救不了哈希溢出到磁盘。
