PostgreSQL原生不支持增量刷新，REFRESH MATERIALIZED VIEW始终全量重算；CONCURRENTLY仅避免读锁但仍是全量执行+比对，真正增量需依赖pg_matview等扩展或手动维护位点+upsert逻辑。

REFRESH MATERIALIZED VIEW 是全量重算，不是增量更新，每次执行都会丢弃旧数据、重新跑一遍原始 SELECT 查询。

REFRESH MATERIALIZED VIEW 基本用法与锁行为

不带 CONCURRENTLY 的刷新会获取排他锁（ACCESS EXCLUSIVE），期间其他查询无法读取该物化视图；加了 CONCURRENTLY 则只加共享锁，允许并发读，但要求物化视图上存在唯一索引（如 CREATE UNIQUE INDEX ON my_mv (id)）。

• REFRESH MATERIALIZED VIEW my_mv：默认带 WITH DATA，刷新后可立即查询
• REFRESH MATERIALIZED VIEW my_mv WITH NO DATA：清空内容，状态变为不可扫描，需后续再带数据刷新才能查
• 刷新失败时，物化视图保持原状（不会残留半新半旧数据）
• 如果原始定义含 ORDER BY，刷新结果才保证有序；否则顺序不确定

REFRESH MATERIALIZED VIEW CONCURRENTLY 的限制条件

这个选项看似友好，但容易因索引缺失或结构变更直接报错，常见错误包括：

• ERROR: cannot refresh materialized view "my_mv" concurrently because it does not have a unique index：必须提前建好覆盖所有行的唯一索引（主键或组合唯一键均可）
• 若物化视图定义中用了 DISTINCT ON 或窗口函数，即使有唯一索引也可能不支持 CONCURRENTLY
• 刷新过程仍会全量执行底层查询，只是比非并发模式多做一次“逐行比对 + 差异更新”，性能未必更快，且不减少 I/O 和 CPU 消耗
• 不能在事务块里使用 CONCURRENTLY 版本

为什么没有真正的增量刷新？

PostgreSQL 15 及之前版本内核不提供基于日志或变更捕获的增量机制。所谓“增量”只能靠外部手段模拟：

• pg_matview 扩展本质是把物化视图变成一张普通表 + 触发器记录变更 + 用户手写 INSERT ... ON CONFLICT 逻辑，它不自动推导哪几行变了
• 手动实现需自己维护刷新位点（比如存进 matview_refresh_state 表），并在刷新 SQL 中加 WHERE updated_at > last_updated
• 任何“增量”方案都绕不开源表要有可靠单调递增字段（如自增 ID、严格递增时间戳），否则无法准确界定变化边界
• 别指望 REFRESH MATERIALIZED VIEW CONCURRENTLY 是增量——它只是避免锁表，背后仍是全量 SELECT + 全量比对

定时刷新的实用做法（不用 pg_cron 也能跑）

最轻量的方式是在 shell 里用 psql 配合 \watch，适合开发/测试环境：

psql -c "REFRESH MATERIALIZED VIEW CONCURRENTLY sales_summary;" \watch 300

生产环境建议用 pg_cron 扩展（需启用并配置 shared_preload_libraries）：

• SELECT cron.schedule('refresh-sales-summary', '0 * * * *', $$REFRESH MATERIALIZED VIEW CONCURRENTLY sales_summary$$);
• 注意：调度任务失败不会自动重试，需查 cron.job_run_details 表确认状态
• 若刷新耗时波动大，避免固定高频调度（如每分钟），防止任务堆积

真正难的从来不是怎么调用 REFRESH MATERIALIZED VIEW，而是判断“什么时候该刷”和“刷完怎么验证数据一致性”——这两点几乎从不写在文档里，却决定线上是否出问题。