答案：优化PostgreSQL聚合查询需创建合适索引、使用覆盖索引减少回表、启用并行执行、避免低效COUNT(DISTINCT)、利用物化视图预聚合及分区表局部扫描，结合查询模式合理设计索引与结构。
PostgreSQL 中的聚合查询（如 SUM、COUNT、AVG、GROUP BY）在处理大量数据时容易变慢。优化这类查询的核心是减少扫描的数据量、提升执行计划效率以及合理使用索引和结构设计。以下是几个关键优化策略。
1. 为 GROUP BY 和 WHERE 字段创建合适的索引
如果聚合查询中包含 GROUP BY 或 WHERE 条件，确保相关字段上有合适的索引。
- 对 GROUP BY 的字段建立索引，可加快分组速度。
- 对 WHERE 中的过滤字段建立索引，减少需要聚合的行数。
- 使用复合索引（多列索引）来覆盖查询中的多个条件字段。
例如，查询：
SELECT user_id, COUNT(*) FROM orders WHERE status = 'completed' GROUP BY user_id;
可创建复合索引：
CREATE INDEX idx_orders_status_user ON orders (status, user_id);
这个索引支持快速过滤 status，同时避免排序或额外查找 user_id。
2. 使用覆盖索引减少表访问
如果索引包含了查询所需的所有字段，PostgreSQL 可以仅扫描索引而不用回表，称为“索引覆盖”。
上面的复合索引 (status, user_id) 就是一个覆盖索引的例子，因为 COUNT(*) 不需要访问实际数据页。
对于更复杂的聚合，如包含其他字段，可以考虑将常用字段加入索引的 INCLUDE 子句（PostgreSQL 11+）：
CREATE INDEX idx_orders_covering ON orders (status) INCLUDE (user_id, amount);
3. 调整查询并行执行设置
PostgreSQL 支持并行聚合（Parallel Aggregation），在大表上能显著提速。
- 确保 max_parallel_workers_per_gather 设置合理（如 4 或 8）。
- 表足够大时，并行才启用；可通过 ALTER TABLE ... SET (parallel_workers = N) 提示优化器。
- 注意：某些聚合函数（如 DISTINCT）可能限制并行能力。
查看执行计划是否启用并行：
EXPLAIN (ANALYZE, BUFFERS) SELECT ...
观察是否有 Parallel Seq Scan 或 Gather 节点。
4. 避免低效的 COUNT(DISTINCT) 写法
COUNT(DISTINCT col) 在大数据集上开销大，因为它需要排序或哈希去重。
优化方法：
- 如果精度允许，使用近似函数：approx_count_distinct（需安装 hyperloglog 扩展）。
- 提前在物化视图中预计算去重统计。
- 拆分聚合逻辑，先用子查询去重再计数，有时能更好利用索引。
5. 使用物化视图预聚合数据
对于频繁执行的聚合查询，尤其是报表类场景，可使用物化视图预先计算结果。
例如：
CREATE MATERIALIZED VIEW mv_daily_sales AS
SELECT date(order_time), product_id, SUM(amount) AS total_amount, COUNT(*) AS order_count
FROM orders
GROUP BY date(order_time), product_id;
然后定期刷新：
REFRESH MATERIALIZED VIEW CONCURRENTLY mv_daily_sales;
这样查询直接从聚合后的数据读取，性能提升明显。
6. 分区表 + 局部聚合
对按时间或范围分区的大表，PostgreSQL 可以只扫描相关分区，大幅减少数据量。
结合局部索引，在每个分区内部高效执行聚合，最后合并结果。
例如按月分区订单表，查某个月的销售统计，只需扫描一个分区。
基本上就这些实用方法。关键是根据查询模式选择合适索引、考虑并行能力、必要时用物化视图或分区来降低实时计算压力。不复杂但容易忽略细节，比如索引顺序或是否真正覆盖查询字段。
