GROUP BY内存爆掉主因是哈希表膨胀、排序失控或临时表写盘；应通过EXPLAIN分析执行计划定位HashAggregate溢出、Using temporary等信号，优先优化索引、前置WHERE过滤、使用覆盖索引及ORDER BY NULL禁用隐式排序。
GROUP BY 内存爆掉，不是数据量大就一定得加内存——它往往卡在哈希表膨胀、排序失控或临时表写盘上。直接调 work_mem 或 max server memory 是治标，关键得看执行计划里到底卡在哪一步。
怎么看是不是 HashAggregate 在吃内存？
先跑 EXPLAIN (ANALYZE)（PostgreSQL）或带 SET STATISTICS XML ON 的查询（SQL Server），重点盯这几个信号：
-
HashAggregate出现在执行计划里，且后面跟着temp file或spilled to disk - SQL Server 执行计划中
GrantedMemory_KB和UsedMemory_KB接近甚至Used>Granted - MySQL 的
Extra列出现Using temporary，且type是ALL或index
这些不是“可能慢”，是已经内存溢出的明确证据。
怎么让 GROUP BY 少占内存？
核心思路是：不让数据库把全量数据塞进哈希表。有三条实操路径：
- 强制走
SortAggregate：在 PostgreSQL 中，GROUP BY a, b ORDER BY a, b（顺序、方向、列名完全一致）能触发流式聚合，只缓存当前分组状态 - 提前过滤：
WHERE条件越靠前越好，比如SELECT dept, COUNT(*) FROM emp WHERE status = 'active' GROUP BY dept，别等全表扫完再分组 - 用覆盖索引避免回表：MySQL 中，如果
SELECT dept, COUNT(*) FROM t GROUP BY dept，建INDEX (dept)就够；若还选了name，就得INDEX (dept, name)，否则仍要读行数据
SQL Server 专属坑：内存 grant 不够还硬扛
它不靠全局内存配置，而靠单次查询的内存授予（query memory grant）。常见错觉是“我把 max server memory 调高了，GROUP BY 就该快”——其实没用。
- 查实时内存分配：
SELECT * FROM sys.dm_exec_query_memory_grants，关注required_memory_kb和granted_memory_kb差距大的查询 - 手动保底：加
OPTION (MIN_GRANT_PERCENT = 25, MAXDOP 2)，比瞎开MAXDOP 0稳定得多 - 别信
QUERYTRACEON 8649：未公开开关，2019+ 版本易污染 plan cache，且行为不可控
字符串分组和高基数字段最伤内存
同样 100 万行，GROUP BY user_id（BIGINT）比 GROUP BY email（VARCHAR(255)）内存占用高 3–5 倍——哈希计算慢、字符串比较重、哈希桶冲突多。
- 能转数字就转：比如把状态码映射成
TINYINT，别用VARCHAR(20)存 “pending”, “done” - 高基数字段慎用：
request_id、trace_id这类几乎唯一值，GROUP BY 几乎等于全量建哈希表，考虑是否真需要分组，或改用物化汇总表预计算 - MySQL 中
ORDER BY NULL可禁用隐式排序：当不需要结果有序时，GROUP BY x ORDER BY NULL能省掉一次排序开销
真正难优化的从来不是语法，而是分组键本身的设计——如果业务上必须按长字符串或 UUID 分组，那再好的索引和内存设置也救不了哈希表爆炸。这时候该想的不是怎么调优，而是能不能换粒度、加缓存、或者改用流式处理框架预聚合。
