在使用PostgreSQL的过程中，不少开发者会发现普通视图的查询速度远不如预期，尤其是当视图关联的表数据量较大、查询逻辑包含多表关联或者聚合计算时，延迟会非常明显。要解决这个问题，物化视图是一个常用的优化方案，但如果使用不当，物化视图也可能出现性能瓶颈。
一、为什么PostgreSQL普通视图查询慢
首先要明确PostgreSQL中普通视图的本质：它只是一个保存起来的SQL查询语句，并不是实际存储数据的表。每次对普通视图执行查询时，数据库都会重新执行视图定义里的SQL，再去底层表拉取数据做计算，具体慢的原因主要有这几个：
- 重复执行复杂逻辑：如果视图定义里包含多表JOIN、GROUP BY、聚合函数（比如SUM、COUNT）等操作，每次查询都要重新跑一遍这些计算，数据量大的时候耗时就会很长。
- 无法有效利用底层表索引：普通视图查询时，优化器可能无法完全下推查询条件到最底层的表，导致索引失效，只能做全表扫描。
- 数据实时性带来的额外开销：普通视图要保证数据和底层表完全一致，每次查询都要读取最新的底层数据，没有缓存机制，频繁查询时开销会叠加。
二、物化视图的优势与潜在性能问题
物化视图和普通视图不同，它会在创建或者刷新的时候，把查询的结果实际存储到磁盘上，后续查询直接读取存储好的数据，不需要重新执行复杂SQL，天然就比普通视图快很多。但它也不是完全没有性能问题：
- 如果物化视图没有合适的索引，查询时还是会做全表扫描，尤其是数据量达到百万级以上时，速度会明显下降。
- 刷新策略选择不当，比如频繁全量刷新，会占用大量IO和CPU资源，还可能影响业务查询。
- 物化视图的定义SQL本身不够优化，比如关联了不必要的表、没有提前过滤数据，存储的数据冗余多，也会影响查询效率。
三、物化视图优化详细步骤
1. 优化物化视图的创建语句
创建物化视图的时候，就要尽量让存储的数据更精简，减少不必要的计算。比如提前过滤掉不需要的数据，只关联必要的表：
-- 不好的创建方式：关联了不必要的表，没有提前过滤 CREATE MATERIALIZED VIEW mv_user_order_bad AS SELECT u.id, u.name, o.order_id, o.amount, o.create_time FROM users u LEFT JOIN orders o ON u.id = o.user_id LEFT JOIN order_extras oe ON o.order_id = oe.order_id; -- 多余的关联 -- 优化后的创建方式：只关联需要的表，提前过滤无效数据 CREATE MATERIALIZED VIEW mv_user_order_good AS SELECT u.id, u.name, o.order_id, o.amount, o.create_time FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE o.status = 1 -- 只保留有效订单 AND o.create_time >= '2024-01-01'; -- 只保留需要的时段数据
2. 为物化视图创建合适的索引
物化视图存储了实际数据，完全可以像普通表一样创建索引，这是提升查询速度最有效的方式。需要根据查询的条件来创建对应的索引：
-- 如果经常按用户ID查询物化视图数据 CREATE INDEX idx_mv_user_order_user_id ON mv_user_order_good(user_id); -- 如果经常按订单创建时间范围查询 CREATE INDEX idx_mv_user_order_create_time ON mv_user_order_good(create_time); -- 如果是多条件查询，可以创建联合索引 CREATE INDEX idx_mv_user_order_user_time ON mv_user_order_good(user_id, create_time);
要注意不要创建过多无用的索引，因为物化视图刷新时，索引也需要同步更新，索引太多会拖慢刷新速度。
3. 选择合适的刷新策略
物化视图的刷新分为全量刷新和增量刷新，要根据业务对数据实时性的要求来选择：
| 刷新方式 | 语法 | 适用场景 | 性能影响 |
|---|---|---|---|
| 全量刷新 | REFRESH MATERIALIZED VIEW mv_name; | 数据实时性要求低，允许定期更新 | 会清空原有数据重新写入，数据量大时耗时久，会阻塞查询（PostgreSQL 12+可以用CONCURRENTLY选项避免阻塞） |
| 并发全量刷新 | REFRESH MATERIALIZED VIEW CONCURRENTLY mv_name; | 数据实时性要求低，但是不能中断查询 | 不会阻塞查询，但是需要物化视图有唯一索引，刷新速度比普通全量刷新慢一点 |
| 增量刷新 | 需要借助触发器或者第三方工具实现 | 数据实时性要求高，底层表变更少 | 只更新变更的数据，刷新速度快，但是实现复杂度高 |
如果业务允许数据有少量延迟，建议每天凌晨等业务低峰期做全量刷新，或者使用并发刷新避免影响白天业务。
4. 优化查询物化视图的SQL语句
即使物化视图本身已经优化过，查询的时候也要注意写法，避免不必要的性能损耗：
- 尽量只查询需要的字段，不要用SELECT *，减少数据传输和处理的开销。
- 查询条件要尽量使用物化视图上已经创建的索引字段，避免索引失效。
- 如果查询需要关联其他表，尽量把关联逻辑放在物化视图的定义里，而不是查询的时候再关联。
-- 不好的查询方式：查所有字段，条件没有用到索引 SELECT * FROM mv_user_order_good WHERE amount > 100; -- 优化的查询方式：只查需要的字段，条件用到了已有的user_id索引 SELECT user_id, name, order_id, amount FROM mv_user_order_good WHERE user_id = 123 AND create_time >= '2024-06-01';
四、注意事项
使用物化视图的时候还要注意几个点：首先物化视图的数据不是实时的，如果业务要求查询到最新的数据，要么选择增量刷新，要么在查询前手动刷新。其次物化视图会占用额外的磁盘空间，要定期清理不需要的物化视图，避免空间浪费。最后如果底层表的结构发生了变更，比如删除了某个字段，要及时检查关联的物化视图是否还能正常使用，避免出现查询报错。
按照上面的步骤优化之后，PostgreSQL的物化视图查询速度通常能有数倍到数十倍的提升，完全可以解决普通视图查询慢的问题。
PostgreSQL物化视图查询优化视图性能修改时间：2026-05-30 21:33:14