refresh materialized view 不加 concurrently 会获取 access exclusive 锁，阻塞所有 select 和 ddl 操作；加 concurrently 需唯一索引，仍持 share update exclusive 锁，不阻塞读但增耗资源且存在短暂不一致。
REFRESH MATERIALIZED VIEW 不加 CONCURRENTLY 时会锁死查询
不带 CONCURRENTLY 的刷新会获取 ACCESS EXCLUSIVE 锁，整个刷新过程中，任何对物化视图的 SELECT 都会被阻塞，直到刷新完成。这不是“慢”，而是直接挂起——连接卡在 waiting 状态，pg_stat_activity 里能看到 state = 'active' 但 wait_event_type = 'Lock'。
- 即使只刷新 10 万行，若底层查询含多表 JOIN 或聚合，执行时间稍长（比如 2–5 秒），应用层就可能触发超时或重试
- 该锁还会阻止其他 DDL（如
ALTER MATERIALIZED VIEW、CREATE INDEX），容易引发运维操作排队 - 没有例外：哪怕物化视图刚创建、数据为空，只要没加
CONCURRENTLY，照样锁
REFRESH MATERIALIZED VIEW CONCURRENTLY 并不等于“无锁”
CONCURRENTLY 只是把锁从“全表排他”降级为“行级比对锁”，它仍需读取旧数据做逐行 diff，因此仍会持有 SHARE UPDATE EXCLUSIVE 锁，并发读可以继续，但写操作（尤其是对物化视图本身执行 TRUNCATE 或 DROP）仍会被阻塞。
- 必须提前建好覆盖全部行的唯一索引，例如
CREATE UNIQUE INDEX ON mv_name (id)；缺索引直接报错：ERROR: cannot refresh materialized view "mv_name" concurrently because it does not have a unique index - 如果物化视图定义含
DISTINCT ON、窗口函数或未显式指定ORDER BY，即使有唯一索引，PostgreSQL 也可能拒绝并发刷新 - 刷新期间，物化视图内容仍是“旧的”，新数据是逐步 merge 进去的，所以某次
SELECT可能读到部分更新、部分未更新的混合状态（虽然不会崩，但业务逻辑需容忍这种短暂不一致）
CONCURRENTLY 刷新为什么更慢，且资源消耗更高
它不是“边查边写”，而是先全量跑一遍原始 SELECT 得到新结果集，再逐行比对旧数据（依赖唯一索引定位），对差异行执行 INSERT/UPDATE/DELETE。这个过程比直接 TRUNCATE + INSERT 多出一次全量扫描 + N 次索引查找 + 更多 WAL 写入。
- 实测 400 万行数据，
REFRESH MATERIALIZED VIEW耗时约 30s，而CONCURRENTLY版本常达 150s+，I/O 和 CPU 使用率明显抬高 - 它不减少底层查询压力：无论是否并发，原始 SELECT 都要完整执行一遍，基表负载照旧
- 若唯一索引字段选择不当（比如用低基数列如
status），diff 阶段的行定位效率骤降，性能进一步恶化
真正想避免查询中断，得绕开物化视图原生机制
PostgreSQL 原生命令做不到“零感知刷新”。CONCURRENTLY 是妥协方案，不是银弹。生产中更可靠的路径是：用分区交换（CREATE TABLE AS + ALTER TABLE ... ATTACH PARTITION）或双表切换（维护两个物化视图，轮流刷新+原子重命名），再配合应用层路由。
- 别依赖触发器自动刷新：资料明确指出，
AFTER INSERT OR UPDATE触发器调用REFRESH MATERIALIZED VIEW CONCURRENTLY会导致写入延迟飙升，尤其在高频写场景下 - 如果必须定时刷新，优先用
pg_cron调度标准刷新（非并发），并安排在低峰期；并发刷新只用于无法接受秒级查询中断的在线报表类服务 - 注意：所有刷新操作都不保证实时性——哪怕每分钟刷一次，数据也至少滞后一分钟；真要近实时，得上逻辑复制或
pg_ivm这类增量扩展
