PostgreSQL 14 中 GROUP BY 性能提升关键在 work_mem 配置、分组键设计及并行扫描配合；盲目建索引或调全局参数反而损害性能。
PostgreSQL 14 的 GROUP BY 本身不加速，真正起效的是 work_mem 配置 + 合理分组键设计 + 并行扫描配合；盲目建索引或改全局参数反而容易拖垮整体性能。
为什么调大 work_mem 能让 GROUP BY 快起来
GROUP BY 在 PostgreSQL 中默认走哈希聚合（HashAggregate）或排序聚合（Sort + GroupAggregate），两者都强依赖内存。一旦中间结果集超出 work_mem 限制，就会写临时文件到磁盘——IO 开销比内存操作高 2–3 个数量级。
实操建议：
- 先用
EXPLAIN (ANALYZE, BUFFERS)看执行计划，重点找HashAggregate或Sort节点下的Disk Usage字段：只要 > 0，就说明已落盘 - 在业务查询前加
SET LOCAL work_mem = '32MB'（别用SET work_mem全局改） - 估算下限：若分组后结果约 50 万行，键字段平均长度 16 字节，预留 1.5 倍膨胀，
work_mem至少设为'12MB' - 别超过
'128MB'单次设置，尤其在连接池 > 30 的服务上，否则可能触发系统 swap
GROUP BY 分组键怎么选才不拖慢查询
PostgreSQL 的 GROUP BY 不像 MySQL 那样能靠索引“跳着读”，但它对分组键的区分度和宽度极度敏感：键越宽、值越重复，哈希桶越多、内存占用越大、缓存局部性越差。
实操建议：
- 避免直接用
user_agent、url、ip这类长文本字段分组；先提取特征（如substr(user_agent, 1, 32)）或映射成 ID（如ua_id） - 多列分组时，把高基数列（如
region）放前面，低基数列（如status）放后面，利于哈希分布更均匀 - 确认
n_distinct统计是否准确：查SELECT n_distinct FROM pg_stats WHERE tablename = 'logs' AND attname = 'service'；若为 -1（全唯一）但实际只有几十个取值，说明需ANALYZE logs - 不用
WITH ROLLUP，它在千万级原始数据上极易生成百万级中间汇总行；真要下钻，拆成两层查询更稳
并行查询要不要开？怎么开才安全
PostgreSQL 14 默认允许并行，但是否启用取决于优化器成本估算。对 GROUP BY 类聚合，并行主要加速前期扫描阶段，后续哈希/排序仍串行——所以收益有上限，但确实可观。
实操建议：
- 确认表大小超阈值：查
pg_total_relation_size('logs')，若 > 32MB，max_parallel_workers_per_gather才可能生效 - 会话级开启更可控：
SET LOCAL max_parallel_workers_per_gather = 3（设为 CPU 核数减 1） - 同步调低成本参数防误判：
SET LOCAL parallel_setup_cost = 200、SET LOCAL parallel_tuple_cost = 0.02 - 禁用某次查询的并行（比如你发现它抢光了内存）：
SET LOCAL max_parallel_workers_per_gather = 0
时间字段分组总出错？UTC 是唯一解
日志表里 created_at 是 TIMESTAMP WITHOUT TIME ZONE，但应用写入时用的是东八区时间，而数据库服务器时区是 UTC——这时 GROUP BY DATE(created_at) 会把凌晨 00:00–00:59 的记录全算进前一天。
实操建议：
- 永远别信服务器本地时区，统一转 UTC 后再分组：
GROUP BY DATE(created_at AT TIME ZONE 'UTC') - 如果字段是
TIMESTAMP WITH TIME ZONE，确保写入时已带时区信息（如'2026-09-28 00:30:00+08'），否则AT TIME ZONE无意义 - 建表达式索引加速：
CREATE INDEX idx_logs_date_utc ON logs ((created_at AT TIME ZONE 'UTC')::DATE)，注意括号不能少 - 验证时区一致性：
SELECT current_setting('timezone'), now(), now() AT TIME ZONE 'UTC'
最易被忽略的一点：GROUP BY 的性能瓶颈往往不在 SQL 写法本身，而在 work_mem 和统计信息这两层“看不见的配置”。一次 ANALYZE 加一次会话级 SET LOCAL，有时比重写十次查询更管用。
