物化视图是PostgreSQL中用于预计算和缓存复杂查询结果的重要对象，特别适合报表统计和数据仓库场景。当底层数据发生变化后，需要通过刷新操作更新物化视图的内容。然而默认的刷新方式会对物化视图加排他锁，阻塞所有读取操作，这在生产环境中往往不可接受。本文将围绕如何使用CONCURRENTLY选项实现无阻塞的并发刷新展开详细讨论。
物化视图刷新的锁机制与阻塞问题
普通刷新命令REFRESH MATERIALIZED VIEW view_name在执行时，PostgreSQL会对物化视图获取AccessExclusiveLock级别的锁。这是PostgreSQL锁体系中级别最高的锁，会与所有其他锁类型冲突，包括最基础的SELECT查询所需的AccessShareLock。这意味着刷新期间，任何尝试读取该物化视图的查询都必须排队等待，直到刷新完成。
对于数据量较大的物化视图，刷新过程可能持续数分钟甚至数十分钟。在这段时间内，依赖该物化视图的应用接口将完全不可用。如果应用层没有做好异常处理和重试机制，还可能引发连接池中的连接被大量占用，最终拖垮整个数据库连接资源。在高并发的互联网应用中，这种阻塞行为是不可接受的。
更棘手的是，如果刷新过程中有长事务正在运行，刷新操作本身也会被阻塞。PostgreSQL在执行刷新前需要等待获取锁，如果此时有一个长时间运行的查询正在读取物化视图，刷新操作只能等待该查询结束后才能开始。这种相互等待的情况在业务高峰期尤为常见，可能导致刷新任务长时间无法执行，数据延迟越来越大，最终影响报表数据的准确性。
CONCURRENTLY选项的原理与使用条件
PostgreSQL从9.4版本开始为REFRESH MATERIALIZED VIEW命令引入了CONCURRENTLY关键字。使用该选项后，刷新过程会获取较低级别的锁，允许读取操作在刷新期间继续执行。具体来说，CONCURRENTLY刷新首先获取ExclusiveLock来阻止写入操作，但允许读取操作继续进行，然后通过内部的多版本并发控制机制完成数据更新。
使用CONCURRENTLY选项有一个硬性前提条件：物化视图上必须存在至少一个UNIQUE索引，且索引列必须覆盖所有行。这个要求是为了在刷新过程中能够通过唯一索引来匹配新旧数据行，从而在不影响读取的情况下完成数据替换。如果尝试在没有唯一索引的物化视图上执行并发刷新，PostgreSQL会直接报错并终止操作。
-- 创建物化视图
CREATE MATERIALIZED VIEW mv_sales_summary AS
SELECT
product_id,
SUM(amount) AS total_amount,
COUNT(*) AS order_count
FROM orders
GROUP BY product_id;
-- 必须先创建唯一索引才能使用并发刷新
CREATE UNIQUE INDEX idx_mv_sales_summary_pid ON mv_sales_summary(product_id);
-- 使用CONCURRENTLY选项刷新
REFRESH MATERIALIZED VIEW CONCURRENTLY mv_sales_summary;需要注意的是，并发刷新在内部实际上会执行两次底层查询：第一次构建新的数据集，第二次通过比较新旧数据来更新物化视图。这意味着并发刷新的执行时间通常比普通刷新更长，消耗的CPU和IO资源也更多。但它的核心优势在于不会阻塞读取操作，业务连续性得到了保障。在大多数生产场景中，牺牲一些刷新速度来换取业务不中断是非常值得的。
此外，并发刷新过程中如果出现错误，物化视图的数据不会处于不一致状态，因为PostgreSQL会在事务中完成所有更新操作。但刷新失败后需要排查错误原因并重新执行，这要求在调度脚本中做好错误处理和重试逻辑。建议在刷新脚本中加入异常捕获和日志记录，便于后续排查问题。
大表物化视图并发刷新的性能优化策略
当物化视图基于千万级甚至亿级数据量时，即使使用CONCURRENTLY选项，刷新过程本身也可能非常耗时。首先需要关注的是底层查询的执行计划。物化视图的刷新本质上是重新执行定义视图时的SELECT语句，因此优化这个查询的执行计划是提升刷新速度的关键。建议使用EXPLAIN ANALYZE工具分析查询执行计划，识别全表扫描、嵌套循环等低效操作。
-- 分析物化视图定义查询的执行计划
EXPLAIN ANALYZE
SELECT
product_id,
SUM(amount) AS total_amount,
COUNT(*) AS order_count
FROM orders
WHERE created_at >= '2023-01-01'
GROUP BY product_id;
-- 确保过滤条件和分组字段有索引支持
CREATE INDEX idx_orders_created_at ON orders(created_at);
CREATE INDEX idx_orders_product_id ON orders(product_id);
-- 对于超大表可考虑分区后分批刷新
CREATE MATERIALIZED VIEW mv_sales_summary_partitioned AS
SELECT
date_trunc('month', created_at) AS month,
product_id,
SUM(amount) AS total_amount
FROM orders
GROUP BY 1, 2;
CREATE UNIQUE INDEX idx_mv_sales_summary_part
ON mv_sales_summary_partitioned(month, product_id);另一个重要的优化方向是控制刷新频率和数据增量。对于频繁更新的数据，全量刷新物化视图的代价过高。可以考虑采用增量刷新策略，即只处理自上次刷新以来发生变化的数据。PostgreSQL本身不直接支持物化视图的增量刷新，但可以通过触发器或逻辑复制机制捕获数据变更，然后通过MERGE或INSERT ON CONFLICT语句将增量数据合并到物化视图中。这种方式特别适合数据按时间递增、历史数据不变的场景。
在调度策略上，建议将物化视图刷新任务安排在业务低峰期执行，并设置合理的超时和重试机制。对于多个物化视图的刷新，应分析它们之间的依赖关系，避免并行执行导致数据库负载过高。可以使用pg_cron扩展或外部调度系统来管理刷新任务的执行计划，确保刷新操作不会对生产业务造成冲击。同时建议为刷新任务设置statement_timeout参数，避免长时间运行的刷新任务占用过多资源。
最后，定期监控物化视图的刷新耗时和底层查询性能变化。随着数据量增长，原本高效的查询可能逐渐变慢，需要及时调整索引策略或重构物化视图定义。通过pg_stat_statements扩展可以追踪刷新语句的执行统计信息，包括执行次数、平均耗时、总耗时等关键指标，为性能优化提供数据支撑。建议建立刷新耗时趋势监控，当发现刷新时间显著增长时及时介入分析和优化。
PostgreSQL物化视图CONCURRENTLY并发刷新修改时间：2026-08-21 04:13:16