GROUP BY 吃内存主因是HashAggregate需全量建哈希表，高基数字段、字符串分组、未过滤数据加剧内存膨胀；改用SortAggregate、提前过滤、物化汇总可有效缓解。
GROUP BY 为什么吃内存？先看执行计划里的 HashAggregate
PostgreSQL 和大多数现代数据库在分组聚合时，默认走 HashAggregate：把所有待分组的行先读进内存建哈希表，键是 GROUP BY 列，值是各聚合函数的中间状态（比如 SUM 的累加值、COUNT 的计数器）。一旦分组键太多或数据量太大，哈希表就爆内存，触发磁盘临时文件（Temp file），性能断崖下跌。
关键判断：如果 EXPLAIN (ANALYZE) 显示 HashAggregate + temp file，或者 work_mem 被频繁打满，就是内存瓶颈了。
- 别盲目调大
work_mem—— 它是每个查询操作符独占的，高并发下反而引发 OOM -
GROUP BY列含大量高基数字段（如user_id、request_id）时，哈希表膨胀极快 - 字符串分组比数字分组更耗内存，因为哈希计算和比较开销大，且字符串本身存储也占空间
用 GROUP BY 前加 ORDER BY 强制走 SortAggregate
当分组键天然有序，或能通过索引快速排序时，SortAggregate 更省内存：它流式处理，只需缓存当前分组的聚合状态，不建全量哈希表。代价是多一次排序（可能走索引避免实际排序）。
实操上，显式加 ORDER BY 是最简单触发方式：
SELECT user_id, COUNT(*) FROM logs GROUP BY user_id ORDER BY user_id;
但注意：ORDER BY 必须和 GROUP BY 完全一致（列名、顺序、方向），否则优化器不会选 SortAggregate。
- 如果已有
(user_id)或(user_id, created_at)索引，ORDER BY user_id很可能直接索引扫描，零排序成本 - 若
GROUP BY是多列（如GROUP BY a, b），ORDER BY a, b才有效；ORDER BY b, a不行 - MySQL 8.0+、SQL Server 也支持类似机制，但叫法不同（如 SQL Server 的
Stream Aggregate）
提前过滤、缩小输入集，比优化聚合本身更有效
内存压力本质来自「参与分组的行数 × 分组键宽度」。减少输入行数永远比调优聚合算法收益更大。
- 把
WHERE条件尽量写紧 —— 比如用created_at >= '2024-01-01'替代无条件查全表 - 避免在
GROUP BY前用JOIN拉宽数据：先聚合再JOIN，而不是JOIN后再聚合 - 对字符串分组字段，考虑是否可转为整型 ID（如用
user_id代替user_email）—— 减少哈希桶大小和比较开销 - PostgreSQL 中，
GROUP BY表达式（如DATE(created_at)）无法走索引，应改用范围条件 + 函数索引
小数据量别硬扛，用物化视图或定时汇总表
如果查询模式固定（比如“每天统计各城市订单量”），实时跑 GROUP BY 是浪费。内存问题的根因常是试图让 OLAP 查询跑在 OLTP 引擎上。
- PostgreSQL 可建
MATERIALIZED VIEW，配合REFRESH控制更新频率 - 更轻量的做法：用
INSERT INTO summary_table ... SELECT ... GROUP BY每小时/每天跑一次，查询直读汇总表 - 注意时区和边界 —— 比如按天汇总时，
WHERE created_at >= CURRENT_DATE - INTERVAL '1 day'要确认是否包含全部昨日数据
真正难的不是怎么写 GROUP BY，而是想清楚：这个聚合结果，是不是必须实时算？很多所谓“性能问题”，其实是需求没对齐导致的硬刚。
