GROUP BY变慢主因是执行路径错误导致全表扫描+哈希聚合或排序，而非语法问题；应通过索引引导优化器选择流式聚合，确保WHERE条件能有效剪枝并避免SARG破坏。
GROUP BY 在千万级数据上变慢，不是语法写错了，而是执行路径选错了。SQL Server 优化器在某些场景下会为 GROUP BY 生成哈希聚合（Hash Aggregate）或排序聚合（Sort + Stream Aggregate），而当分组键基数低、重复值多（比如 app_account 只有 5000 个不同值，却要扫 500 万行），它仍可能走全表扫描+大内存哈希，导致耗时飙升——你看到的 37 秒，大概率卡在哈希构建或溢出到 TempDB。
为什么 DISTINCT 比 GROUP BY 快得多？
这不是玄学，是执行计划本质差异：
- GROUP BY 默认承诺「可扩展性」：它必须为每个分组保留上下文（哪怕你只 SELECT 分组键），可能触发排序、哈希、甚至 spill 到磁盘；
- DISTINCT 只承诺「去重」，优化器更倾向用流式去重（Stream Aggregate）或索引跳扫（Index Seek + Unique Scan），尤其当目标列上有索引时。
常见错误现象：
- 执行计划里出现
Hash Match (Aggregate)且Estimated Row Count远高于实际分组数（如预估 500 万，实际只有 5000 组） - TempDB I/O 突增，
sys.dm_exec_query_stats显示tempdb_allocations高 - 加了
GROUP BY字段的索引，但执行计划仍显示Clustered Index Scan
- 如果你只需要「列出所有不重复的值」（比如
SELECT DISTINCT app_account FROM t WHERE ...），直接换 DISTINCT，别硬扛 GROUP BY；- 如果后续还要
COUNT(*)、MAX(createdate) 等聚合，再考虑其他路径——但先确认是否真需要这些值；- 不要盲目加
ORDER BY NULL，SQL Server 2019 不再因此跳过排序，基本无效。GROUP BY 查询必须用，怎么绕过哈希聚合陷阱？
核心思路：**让优化器相信「分组结果集很小」，从而主动选择索引驱动的流式聚合**。
关键条件：
- 分组字段（如 app_account）上有索引，且该索引是「窄索引」（只含分组列 + 主键/聚簇键）；
- WHERE 条件能利用该索引的前导列做 Seek（不能是 SARG 被破坏的表达式）；
- 避免在分组列上用函数或计算，例如 GROUP BY UPPER(app_account) 会彻底废掉索引。
实操建议：
- 建覆盖索引：
CREATE INDEX IX_t_app_account ON t(app_account) INCLUDE (id);（即使不 SELECT id，INCLUDE 也能帮优化器避免回表，提升流式聚合稳定性）；
- 把 WHERE 条件中高选择性的列前置到索引中，比如
WHERE status = 1 AND app_account IN (...)，索引应建为 (status, app_account)；- 检查执行计划：如果看到
Index Seek → Stream Aggregate → Compute Scalar，说明走对了；若仍是 Hash Match，用 OPTION (QUERYTRACEON 9481) 强制老版优化器（仅调试用，勿上线）。
WHERE 条件太复杂，索引也救不了 GROUP BY？
这是高频误判点：你以为加了组合索引就万事大吉，但 SQL Server 对多条件 AND 的索引匹配极其敏感。
常见错误现象：
- 组合索引是 (a, b, c)，但 WHERE 写成 WHERE b = ? AND c = ?，索引完全失效；
- 用了 OR、IN、LIKE '%xxx'，导致优化器放弃索引走扫描；
- 对字段用 ISNULL()、COALESCE()、CAST()，SARG 被破坏。
实操建议：
- 把 WHERE 中「过滤性最强」的列放在组合索引最左侧（比如 create_date >= '2025-01-01' 比 status IN (1,2,3) 选择性高得多）；
- 用 UNION ALL 拆解 OR：
WHERE app_account = 1001 OR app_account = 2002改为两个
SELECT ... WHERE app_account = 1001 UNION ALL SELECT ... WHERE app_account = 2002；-
IN 列表超过 20 项，考虑用临时表 + JOIN 替代，避免优化器降级为嵌套循环。
真正卡住性能的，往往不是 GROUP BY 本身，而是它被迫在没有索引引导、WHERE 条件又无法剪枝的情况下，对千万行做无差别扫描后再聚合。索引设计、WHERE 写法、聚合意图三者必须咬合——少一个，GROUP BY 就容易退化成「全表扫描+内存暴击」。
