concurrently 刷新不阻塞读但默认更慢，因需全表扫描、双索引比对及行级锁；须有非空唯一索引、首次普通刷新后才可用，仅在读瓶颈且数据变化率低时提升读吞吐。

REFRESH MATERIALIZED VIEW CONCURRENTLY 能避免读阻塞，但不是“开箱即用”的吞吐提升方案——它默认比普通刷新更慢、更耗资源，只有在满足硬性前提且业务能接受最终一致性时，才值得启用。

为什么加了 CONCURRENTLY 反而更慢？

并发刷新不重写整张表，而是走「差集比对」路径：先执行源查询生成临时快照，再用唯一索引逐行比对旧数据与快照，最后只 INSERT/UPDATE/DELETE 差异行。这意味着：

• 必须全量扫描源表（哪怕只改了一行）
• 要两次索引扫描（旧视图索引 + 快照索引）
• 每行变更都触发 WAL 写入和行级锁竞争
• 若底层表在刷新期间被高频写入，可能反复重试比对，拖慢整体事务

CONCURRENTLY 刷新失败的三个典型报错及修复

只要没建对唯一索引，REFRESH MATERIALIZED VIEW CONCURRENTLY 就会直接拒绝执行，不会进入刷新流程。

• ERROR: cannot refresh materialized view "mv_orders" concurrently —— 物化视图上没有 UNIQUE 或 PRIMARY KEY 索引；建索引必须显式执行 CREATE UNIQUE INDEX ON mv_orders (id)，源表主键不会自动同步到 MV
• ERROR: unique index on materialized view must not contain nullable columns —— 索引列含 NULL 值；可用 CREATE UNIQUE INDEX ON mv_orders (COALESCE(id, 0)) 包裹，或加 WHERE id IS NOT NULL
• could not lock updated tuple in materialized view —— 刷新末尾尝试更新某行时，该行已被业务 UPDATE 修改；这不是死锁，是并发写冲突，需重试或调整业务写入逻辑

哪些场景下 CONCURRENTLY 才真能提吞吐？

它提升的是「读请求吞吐」，不是「刷新吞吐」。关键看你的瓶颈是否在查询排队上：

• 报表页面大量 SELECT 并发访问同一物化视图，且无法容忍秒级卡顿 → 启用 CONCURRENTLY 后，读请求照常响应，吞吐稳定
• 物化视图数据变化率低（比如日汇总，每天只增千行），差异小 → 差集计算快，刷新耗时不显著拖累后台任务
• 你已预留足够磁盘空间（临时快照需额外 ~1.5 倍原视图大小），且监控到 pg_stat_progress_refresh_matview 中的 phase 长期卡在 scanning 或 comparing → 说明当前配置可行
• 不能在事务块或函数里调用：REFRESH MATERIALIZED VIEW CONCURRENTLY 不支持嵌套在 BEGIN...END 中，否则报 cannot be executed from a function or multi-statement query

真正容易被忽略的是：即使索引建对、字段非空、列全覆盖，如果物化视图刚用 WITH NO DATA 创建，还没执行过首次填充，CONCURRENTLY 也会直接报错。必须先用普通刷新填一次数据，后续才能并发刷新。