在一个订单量超过千万行的业务库中，一条按地区汇总销售额的查询执行了二十多秒，负责报表的同事几乎每天都要被这个问题折磨。DBA查看执行计划后发现，查询需要多表关联再聚合，而聚合结果的基数其实非常小，可能只有几百行。这种场景正是物化视图（Materialized View）的用武之地：既然结果集小、源数据大、查询频繁，那不如把计算结果直接存下来，查询时读现成的数据。
一、先搞清楚慢查询到底慢在哪里
在动手优化之前，一定要先看执行计划。PostgreSQL提供了EXPLAIN ANALYZE命令，它会真正执行这条语句并输出每个节点的实际耗时。对于聚合类慢查询，通常会看到以下几种情况：多表JOIN导致中间结果集膨胀、GROUP BY需要大量排序或哈希计算、扫描方式走了全表扫描（Seq Scan）而不是索引扫描。
以一个典型场景为例：订单表orders有两千万行，地区维表regions有几千行，报表按地区统计每天的销售额。这条查询每次执行都要重新扫描全部订单数据并做聚合，即使加了索引，聚合计算本身的代价也无法避免。这类查询有个共同特征：计算过程很重，但结果很小且变化不频繁。如果业务允许数据有几秒甚至几分钟的延迟，把这些重计算的结果固化下来就是最直接有效的优化手段。
EXPLAIN ANALYZE
SELECT r.region_name,
DATE_TRUNC('day', o.created_at) AS stat_date,
SUM(o.amount) AS total_amount,
COUNT(*) AS order_count
FROM orders o
JOIN regions r ON r.region_id = o.region_id
GROUP BY r.region_name, DATE_TRUNC('day', o.created_at);
执行计划里如果出现了Seq Scan on orders加上GroupAggregate的组合，并且耗时集中在扫描和聚合节点上，基本可以判定这是CPU和IO双重密集型的查询，单纯加索引收效有限，此时就该考虑物化视图了。
二、物化视图的创建与刷新机制
物化视图的语法非常简单，本质上就是把一条SELECT语句的结果存储为一张实际的物理表。普通视图只存储查询定义，每次查询都会重新执行底层SELECT；而物化视图把结果数据实实在在写到磁盘上，查询时直接读取，性能等同于查一张普通表。
-- 创建物化视图
CREATE MATERIALIZED VIEW mv_region_sales AS
SELECT r.region_name,
DATE_TRUNC('day', o.created_at) AS stat_date,
SUM(o.amount) AS total_amount,
COUNT(*) AS order_count
FROM orders o
JOIN regions r ON r.region_id = o.region_id
GROUP BY r.region_name, DATE_TRUNC('day', o.created_at);
-- 物化视图同样支持索引
CREATE UNIQUE INDEX idx_mv_region_sales
ON mv_region_sales (region_name, stat_date);
-- 全量刷新（会加排他锁，阻塞查询）
REFRESH MATERIALIZED VIEW mv_region_sales;
-- 推荐方式：并发刷新（不阻塞查询，但需要唯一索引）
REFRESH MATERIALIZED VIEW CONCURRENTLY mv_region_sales;
这里有两个关键点值得展开。第一，物化视图创建后并不会自动更新，必须显式调用REFRESH MATERIALIZED VIEW。全量刷新会先锁住视图再重建数据，期间所有查询都会被阻塞；而CONCURRENTLY选项可以在刷新过程中保持视图可读，代价是需要满足两个前提：物化视图上必须存在唯一索引，且刷新过程整体耗时更长。对线上业务来说，几乎都应优先选择并发刷新。
第二，刷新的触发方式需要根据业务设计。常见做法有三种：用cron定时执行psql脚本、用pg_cron扩展在数据库内部调度、或者在业务低峰期通过应用代码触发。如果源表有明确的更新时间戳字段，还可以实现增量刷新思路：只把最近变更的数据合并进物化视图，进一步降低刷新成本。
三、物化视图、普通视图与汇总表的选择
很多人容易把物化视图和手工维护的汇总表搞混。手工汇总表需要自己写INSERT、UPDATE、DELETE逻辑来维护数据一致性，逻辑一旦复杂就容易出bug；物化视图则由数据库负责重建结果，你只需要维护刷新策略，出错概率低得多。普通视图则适合那些查询本身很快、只是想简化SQL复用的场景，它没有任何性能加速作用。
| 方案 | 数据实时性 | 性能提升 | 维护成本 |
|---|---|---|---|
| 普通视图 | 实时 | 无提升 | 最低 |
| 物化视图 | 取决于刷新频率 | 显著 | 低，维护刷新任务即可 |
| 手工汇总表 | 可做到准实时 | 显著 | 高，需自行维护一致性 |
选择建议很明确：查询慢但数据要求严格实时时，优先考虑改写SQL、加索引或调整参数；数据允许分钟级延迟、且查询模式固定（典型如报表、看板）时，物化视图是性价比最高的方案；只有当需要秒级近实时增量更新、且物化视图刷新代价过高时，才值得投入精力做手工汇总表或流式计算。
四、实战效果与注意事项
回到前面那个订单报表的例子。将查询改为读取物化视图后，原本二十多秒的查询降到了几十毫秒，因为数据量从两千万行聚合变成了直接读取几百行现成结果，同时配合(region_name, stat_date)上的索引，按条件过滤的报表查询可以直接走索引扫描。刷新任务配置为每小时执行一次并发刷新，单次刷新耗时约八秒，整体完全可接受。
使用物化视图还有几个容易踩的坑需要留意。首先，并发刷新依赖唯一索引，而唯一索引要求物化视图的结果集在业务上确实唯一，如果汇总粒度不够细导致重复行，就需要调整GROUP BY维度。其次，刷新本身是对源表的完整查询，会给主库带来周期性压力，大表场景下建议安排在低峰期，或直接在只读副本所在的链路上处理（注意物化视图需要能写入，纯只读副本上不可行）。最后，记得监控刷新耗时，如果刷新时间随着数据增长持续变长，说明该考虑增量刷新或分表分视图拆分了。
总结一下优化路径：先用EXPLAIN ANALYZE确认瓶颈在重计算而非简单扫描，再评估业务对数据延迟的容忍度，然后创建物化视图、加上唯一索引、配置并发刷新任务。整个过程不需要改动任何业务表结构，是一种侵入性极低、见效却非常明显的慢查询治理手段。
PostgreSQL慢查询物化视图查询优化修改时间：2026-09-09 09:26:51