GROUP BY内存溢出主因是哈希表缓存分组键与聚合值超限，非调sort_buffer_size可解；应优先建覆盖索引、精简字段、分片查询，再合理设PostgreSQL的work_mem或MySQL的tmp_table_size/max_heap_table_size。
GROUP BY 内存溢出不是加 sort_buffer_size 就能解决的——它根本不管聚合内存，真正该动的是 work_mem（PostgreSQL）或临时表阈值（MySQL），而最有效的解法往往在索引和查询结构里。
为什么 GROUP BY 会触发 Out of memory 错误
数据库执行 GROUP BY 时，会把分组键和聚合值（如 SUM()、COUNT(DISTINCT)）缓存在内存哈希表中。一旦分组数超千万，或某一分组数据量极大（比如一个 user_id 对应 400 万条日志），哈希表就直接撑爆内存。
- PostgreSQL 看
work_mem：设太小会 fallback 到磁盘排序（SORTAGG），但依然占内存；设太大则并发一高就 OOM - MySQL 不靠
sort_buffer_size控制聚合，而是由tmp_table_size和max_heap_table_size共同决定内存临时表上限 - MySQL 8.0+ 的 CTE 聚合默认不物化，
WITH t AS (SELECT ...) SELECT COUNT(*) FROM t GROUP BY x仍可能 OOM，得加MATERIALIZED提示
MySQL 中如何避免 GROUP BY 内存溢出
调参只是兜底，优先从查询本身入手：
- 给
GROUP BY字段建联合索引，且把WHERE条件字段放最左：例如SELECT user_id, COUNT(*) FROM orders WHERE status = 'paid' GROUP BY created_date，应建INDEX(status, created_date) - 避免
SELECT *，只取分组字段和聚合字段，减少临时表单行体积 - 确认
tmp_table_size和max_heap_table_size设为相同值（如536870912，即 512MB），否则 MySQL 取较小者生效 - 用
EXPLAIN FORMAT=TRADITIONAL检查Extra列：出现Using temporary就说明索引没覆盖分组逻辑 - 对超大表，改用主键分片 + 临时表：先
CREATE TEMPORARY TABLE tmp_ids (id BIGINT PRIMARY KEY)插入一批 ID，再JOIN聚合，每次控制在几万行内
PostgreSQL 中 work_mem 怎么设才安全
work_mem 是每个操作（如排序、哈希聚合）独占的内存上限，不是全局池——一个查询里多个 GROUP BY 或嵌套 JOIN 会各自申请一份。
- 查当前值：
SHOW work_mem；单位是 KB，默认通常是 4096（4MB） - 线上建议按需会话级调整：
SET LOCAL work_mem = '64MB'，而非全局硬设 - 设太高会导致并发查询争抢：比如 50 个连接 × 128MB = 6.4GB，远超
shared_buffers容量 - 当
EXPLAIN ANALYZE显示HashAgg节点有Spill to disk，才说明真不够；若没 spill 却 OOM，大概率是查询写法问题（如未下推过滤条件） - 注意：
HASHAGG在work_mem不足时 fallback 到SORTAGG，但SORTAGG仍需内存排序，不是自动落盘
最容易被忽略的三个硬限制
很多调参失败，是因为没看清底层约束：
- MySQL 的
sort_buffer_size对纯GROUP BY几乎无效——它只管ORDER BY排序，不控聚合内存 - PostgreSQL 的
work_mem是 per-operation，不是 per-query；一个含子查询+聚合+排序的语句可能消耗 3×work_mem - 视图里写
ORDER BY或GROUP BY，外层再查，容易强制物化全量结果（DERIVED 表），此时加内存参数毫无意义，必须重写视图或移除内部排序
