大宽表GROUP BY易落盘主因是单行体积大导致哈希表内存超work_mem，且优化器难生成并行计划；须先投影裁剪字段、建覆盖索引、协同调优work_mem与并行参数。
大宽表（字段多、单行体积大）的 GROUP BY 查询在 PostgreSQL 15 中极易触发磁盘落盘、内存爆炸或并行失效——核心矛盾不是“分组逻辑复杂”，而是中间结果集占用内存远超 work_mem 预算，且优化器难以生成高效并行计划。
为什么大宽表 GROUP BY 特别容易落盘？
宽表单行可能达几 KB（比如含多个 TEXT、JSONB、长 VARCHAR 字段），而 GROUP BY 需在内存中维护每组的聚合状态 + 所有非分组列的原始值（除非用 MIN()/MAX() 等可推导函数）。PostgreSQL 不会自动裁剪未参与聚合的宽字段，导致内存用量飙升。
- 查实锤：运行
EXPLAIN (ANALYZE, BUFFERS)，重点看HashAggregate节点的Disk Usage—— 只要 > 0，就是被迫写临时文件 - 更隐蔽的问题：即使没落盘，
Memory Usage接近work_mem上限时，worker 进程会因内存竞争被系统拒绝启动，表现为Workers Launched: 0 - 别信
EXPLAIN的预估：它不计算实际行宽，只按统计信息估算行数，对宽表严重失真
必须先做投影裁剪：SELECT 列只留 GROUP BY 键和必要聚合
这是最立竿见影的一步。大宽表下，SELECT * 或 SELECT a,b,c,... 全字段会把所有列都拖进哈希表，哪怕你只按 user_id 分组。
- 错误写法：
SELECT *, COUNT(*) FROM wide_table GROUP BY user_id—— 把整行都塞进内存 - 正确做法：显式列出分组键和聚合字段，例如
SELECT user_id, COUNT(*), MAX(updated_at), MIN(status) - 如果业务真需要某宽字段的“任意值”，用
MIN(col)或MAX(col)（对TEXT/JSONB也有效），避免ANY_VALUE()（PG 不支持） - 若必须返回完整行，改用窗口函数：
SELECT * FROM (SELECT *, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY updated_at DESC) rn FROM wide_table) t WHERE rn = 1，绕开 GROUP BY 内存瓶颈
work_mem 和并行参数必须协同调优
单独调高 work_mem 治标不治本；不配并行参数，work_mem 再大也只用单核。两者必须按比例设：
- 先确认资源上限：
max_worker_processes≥ CPU 核心数 × 2（如 16 核 → 设 32），否则后续参数无效 - 再设并行基线：
max_parallel_workers= CPU 核心数（如 16 核 → 设 16），max_parallel_workers_per_gather= 4～6（勿 ≥ 8） - 最后定
work_mem：从'32MB'起步，结合查询实际宽度测试。公式参考：work_mem ≈ 行宽 × 分组后行数 × 1.5。例如平均行宽 2KB、分组后 10 万行 → 至少需 300MB，但此时单个查询已吃掉 4 worker × 300MB = 1.2GB，务必评估并发压力 - 生效命令：
SELECT pg_reload_conf()，无需重启
索引和分区能绕过 GROUP BY 吗？
不能直接绕过，但能大幅减少输入数据量，让 GROUP BY 处理更小的结果集——这才是宽表优化的真正杠杆点。
- 复合索引必须覆盖 WHERE + GROUP BY：例如查询
WHERE dept = 'sales' AND status = 'active' GROUP BY user_id，建索引CREATE INDEX idx_wide_dept_status_user ON wide_table (dept, status, user_id) - 分区表按高频过滤字段切分：如按
created_date分区，查询最近 7 天数据时，优化器自动 prune 掉 99% 分区，GROUP BY只扫真实数据子集 - 警惕部分索引陷阱：
WHERE条件选择性低（如status IN ('active','pending')占全表 80%）时，索引反而不如顺序扫描，先用EXPLAIN验证
宽表 GROUP BY 的本质是内存带宽问题，不是算法问题。最容易被忽略的是：你看到的“慢”，往往发生在 HashAggregate 节点启动前——因为优化器发现内存不够，干脆放弃并行，退化成单线程外排。所以别只盯着执行计划末尾，先看 Workers Launched 和 Disk Usage 这两个硬指标。
