GROUP BY内存溢出的根本原因是数据库放弃索引分组而强制使用内存临时表，导致分组键与聚合值全量加载进哈希表；需通过联合索引（WHERE字段在前、GROUP BY字段居中、聚合字段在后）、避免函数和SELECT*、分片查询等优化查询结构，而非仅依赖调参。
GROUP BY 内存溢出不是加 sort_buffer_size 就能解决的——它根本不管聚合内存，真正该调的是 PostgreSQL 的 work_mem 或 MySQL 的 tmp_table_size/max_heap_table_size；但最有效的解法往往在索引和查询结构里，而不是参数。
为什么 EXPLAIN 里总出现 Using temporary
这是数据库放弃索引分组、强制建内存临时表的明确信号。一旦出现，说明分组逻辑无法被索引覆盖，数据全量加载进内存哈希表，分组数一多（比如超千万）或单组数据极大（如一个 user_id 对应 300 万行），就直接撑爆内存。
- 常见诱因：
GROUP BY字段没索引，或索引顺序与查询不匹配（例如索引是(status, user_id)，但写成GROUP BY user_id, status） - 函数干扰：写成
GROUP BY DATE(created_at)或GROUP BY SUBSTRING(name, 1, 5)，索引完全失效 -
SELECT *拖累：即使分组字段有索引，SELECT *仍会触发回表+临时表，单行体积翻倍 - WHERE 条件未覆盖：索引建了
(user_id)，但查询带WHERE status = 'paid'，实际还是全表扫
MySQL 下怎么让 GROUP BY 不落盘
MySQL 没有 work_mem，sort_buffer_size 只管排序，不干预 GROUP BY 临时表行为。真正决定能否走索引分组的是联合索引结构和查询写法。
- 索引必须按三段式建：
WHERE等值字段 →GROUP BY字段 →SELECT中的聚合字段（不含函数）。例如查询SELECT dept_id, COUNT(*) FROM orders WHERE status = 'paid' GROUP BY dept_id，对应索引是INDEX(status, dept_id) - 查执行计划：用
EXPLAIN FORMAT=TRADITIONAL，紧盯Extra列是否出现Using index for group-by；若为Using temporary; Using filesort，说明已失控 - 必须设对两个参数：
tmp_table_size和max_heap_table_size必须显式设为相同值（如256M），否则取较小者生效；且需重启 MySQL 才生效 - 避免在
GROUP BY里混用未被索引的字段，比如GROUP BY user_id, SUBSTRING(name, 1, 10)—— 函数导致索引失效
PostgreSQL 中 work_mem 怎么设才不翻车
work_mem 是每个操作（如排序、哈希聚合）独占的内存上限，不是共享池——一个查询里有 JOIN + GROUP BY + ORDER BY，会各自申请一份，加起来就是三倍消耗。
- 先确认是否真缺内存：运行
EXPLAIN (ANALYZE, BUFFERS)，看Hash Agg节点有没有Spill to disk；没有 spill 却 OOM，大概率是查询逻辑问题 - 别改全局配置：用
SET LOCAL work_mem = '128MB'仅对当前会话生效，避免高并发下集体抢内存 - 设太高反而出事：50 个连接 × 256MB = 12.8GB，远超
shared_buffers，可能把整个实例拖垮 - fallback 不等于安全：
work_mem不足时退化为Sort Agg，它仍需内存排序，不是自动落盘
真正该优先做的三件事
调参只是兜底，90% 的 GROUP BY 内存问题，靠改查询就能绕开。
- 给
GROUP BY字段建联合索引，且把WHERE条件字段放最左：例如SELECT user_id, COUNT(*) FROM logs WHERE created_at >= '2026-01-01' GROUP BY user_id，应建INDEX(created_at, user_id) - 避免
SELECT *，只取分组字段和聚合字段；特别要避开TEXT/BLOB列参与分组 - 对超大表，改用主键分片 + 临时表：先
CREATE TEMPORARY TABLE tmp_ids (id BIGINT PRIMARY KEY)插入一批 ID，再JOIN聚合，每次控制在几万行内
最容易被忽略的一点：高基数字段（如 UUID、email、IP）直接 GROUP BY 是隐形炸弹，哪怕建了索引也救不了哈希表膨胀。这种场景不该硬扛，得提前物化维度（比如加生成列存域名、地区码），或者迁到 OLAP 系统预计算。
