确认GROUP BY是否耗尽work_mem，需运行EXPLAIN (ANALYZE, BUFFERS)并检查HashAggregate节点的Disk Usage>0，或日志中“writing to disk”提示；多字段GROUP BY会指数级放大哈希表内存占用，且索引缺失时参数调优无效。
怎么确认GROUP BY正在吃光work_mem
多字段GROUP BY（比如GROUP BY user_id, status, created_date）本身不增加复杂度，但会显著放大哈希表内存占用——分组键组合数可能从百万级跳到千万级。别猜，直接运行EXPLAIN (ANALYZE, BUFFERS)，重点看HashAggregate节点下的Disk Usage是否大于 0；如果出现Spill to disk或日志里有writing to disk due to insufficient memory，就是work_mem不够用了。
为什么SET work_mem = '128MB'反而让查询更慢
work_mem是每个操作独占的上限，不是整个查询共享的池子。一个含多字段GROUP BY的查询，若还带JOIN和ORDER BY，可能同时触发三份work_mem申请。高并发下盲目调大极易引发连锁OOM：
- 50个连接 ×
work_mem = '128MB'= 6.4GB，远超shared_buffers，系统开始swap - PostgreSQL被迫把部分哈希桶刷到磁盘，反而比小内存+排序更慢
- 多个
HashAggregate争抢同一块临时空间，I/O打满
真正安全的做法是用SET LOCAL work_mem = '32MB'只对当前事务生效，或者在应用层为该查询显式加BEGIN; SET LOCAL work_mem = '64MB'; ... ; COMMIT;。
多字段GROUP BY没走哈希，却卡在Sort Aggregate上怎么办
当work_mem不足时，PostgreSQL会fallback到Sort + GroupAggregate，但它仍需要足够内存做排序——这不是“自动落盘”，而是换了一种吃内存的方式。此时EXPLAIN里会出现Sort节点且Memory Usage接近上限、Disk Usage > 0。
解决路径不是继续加work_mem，而是切换思路：
- 检查分组字段顺序是否匹配现有索引：比如索引是
(status, user_id, created_date)，但写成GROUP BY created_date, user_id，索引就废了 - 删掉
SELECT *，只保留分组字段和聚合字段，减少单行体积 - 用
SELECT COUNT(*) FROM (SELECT 1 FROM t GROUP BY a,b,c) AS _快速验证分组组合数是否爆炸（避免全字段拉取）
分组键基数太高，work_mem再大也扛不住时怎么拆
当GROUP BY组合数超 2000 万，或某组数据量极大（如一个(user_id, status)对应 300 万行），哈希表必然撑爆内存。这时必须放弃单次聚合：
- 按主键范围分片：先
CREATE TEMPORARY TABLE tmp_ids AS SELECT id FROM t WHERE ... ORDER BY id LIMIT 10000 OFFSET 0，再JOIN聚合 - 用时间/分区键切分：如果表按
created_date分区，优先GROUP BY单个分区，再UNION ALL汇总 - 识别倾斜键：运行
SELECT count(*), user_id, status FROM t GROUP BY user_id, status ORDER BY count(*) DESC LIMIT 5，把头部几个热键单独拎出来查
最常被忽略的一点：work_mem调得再精准，也救不了没有覆盖索引的GROUP BY——它连哈希阶段都进不去，直接退化成全表扫描+内存暴增。索引永远比参数调优优先级更高。
