加索引对GROUP BY没用是因为PostgreSQL的GROUP BY不直接使用B-tree索引分组，索引仅辅助定位和排序；若无WHERE或ORDER BY，索引几乎不影响分组速度，瓶颈在于全表扫描及内存中哈希或排序分组。
为什么加索引对GROUP BY没用？
PostgreSQL 的 GROUP BY 本身不直接走 B-tree 索引做分组，索引只帮着快速定位和排序——但如果你的查询没带 WHERE 条件或 ORDER BY，光建索引几乎不影响分组速度。真正卡住的是：全表扫描 + 内存中哈希分组（HashAggregate）或排序分组（GroupAggregate），尤其当分组键组合基数高、行数超千万时。
实操建议：
- 先用
EXPLAIN (ANALYZE, BUFFERS)看执行计划，确认是否走了HashAggregate，以及Work_mem是否够用（看是否有disk: NkB） - 检查分组字段是否都为
NOT NULL，否则 PostgreSQL 可能拒绝使用某些优化路径（如物化视图预计算） - 避免在
GROUP BY中混用表达式和列名，比如GROUP BY a, b + c会让索引失效更彻底
哪些索引能真正起效？
只有满足「前缀匹配 + 排序友好」的复合索引才可能被用于加速 GROUP BY。核心是让 PostgreSQL 能按索引顺序读取数据，边读边分组（触发 GroupAggregate），跳过全表扫描。
实操建议：
- 索引字段顺序必须严格匹配
GROUP BY列顺序，例如查询是GROUP BY region, category, status，就建CREATE INDEX ON sales (region, category, status) - 如果还带
ORDER BY region, category，该索引还能顺便避免排序开销 - 若分组字段有高频过滤条件（如
WHERE date >= '2024-01-01'），把过滤字段放在索引最左，再接分组字段，例如(date, region, category) - 不要给文本字段（如
varchar(500)）建长前缀索引再用于分组——B-tree 对长键排序开销大，反而拖慢
work_mem 设多少才不溢出？
PostgreSQL 默认 work_mem = 4MB，对千万级分组极易触发磁盘临时文件（
HashAggregate (cost=... rows=... width=...) (actual time=... rows=... loops=...)<br> -> HashAggregate (cost=... rows=... width=...) (actual time=... rows=... loops=...)<br> -> Seq Scan on sales (cost=... rows=... width=...)<br> Buffers: shared hit=..., read=..., temp read=..., temp write=...）。一旦出现
temp read/write，性能断崖下跌。
估算公式：work_mem ≈ 分组键平均字节数 × 预估分组数 × 2（留一倍余量）。例如 3 字段分组（int4 + int2 + char(2) ≈ 12B），预计 500 万组 → 至少需 120MB。
实操建议：
- 在会话级临时调大：
SET LOCAL work_mem = '128MB';（仅影响当前查询，安全） - 生产环境慎改全局
work_mem，优先用ALTER TABLE ... SET (parallel_workers = 4)让聚合并行化（PG 15 默认支持并行HashAggregate） - 监控
pg_stat_database.blk_read_time和temp_files，发现突增就是work_mem不足信号
物化视图 or 分区表？选哪个更实际？
物化视图适合「分组维度固定 + 数据更新不频繁」场景（如日报统计）；分区表则适合「按时间/地域切分 + 查询常带分区键过滤」的大宽表。两者不是互斥，可以共用。
实操建议：
- 用 PG 15 原生物化视图（
CREATE MATERIALIZED VIEW ... REFRESH CONCURRENTLY），避免锁表；但注意它不自动刷新，需配合pg_cron或应用层调度 - 如果表已按
date分区，且查询总带WHERE date BETWEEN ...，那么只需扫描几个分区，GROUP BY自然变快——比任何索引都管用 - 别为了 GROUP BY 强行引入分区，尤其当分区键和分组键完全不重合（如按
id分区却按user_id, tag分组），只会增加规划器负担
最易被忽略的一点：GROUP BY 性能瓶颈常常不在 SQL 写法，而在统计信息不准。记得定期跑 ANALYZE table_name，特别是大批量 INSERT/UPDATE 后——否则规划器可能误判分组基数，选错执行路径。
