REFRESH MATERIALIZED VIEW 不加 CONCURRENTLY 会获取 ACCESS EXCLUSIVE 锁，阻塞所有 SELECT 直至刷新完成；加 CONCURRENTLY 需满足唯一索引、非空列、全覆盖分组列三条件，否则报错，且仍持 SHARE UPDATE EXCLUSIVE 锁，不阻塞读但阻塞 DDL 和部分 DML，并存在短暂数据不一致。

REFRESH MATERIALIZED VIEW 为什么会让 SELECT 卡住

不加 CONCURRENTLY 的刷新会拿 ACCESS EXCLUSIVE 锁，整个物化视图在刷新期间对所有 SELECT 不可见。你看到的不是慢，是连接卡在 wait_event_type = 'Lock'，pg_stat_activity 里状态仍是 'active'。哪怕只刷 10 万行，只要底层查询含 JOIN 或聚合，几秒就能让应用超时。

CONCURRENTLY 刷新必须满足的三个硬条件

缺一不可，否则直接报错：ERROR: cannot refresh materialized view "xxx" concurrently, because it does not have a unique index。

• 物化视图上必须有显式创建的 UNIQUE 或 PRIMARY KEY 索引（基表主键不会自动继承）
• 索引列全部为 NOT NULL；如果源字段允许 NULL，得用 COALESCE(col, 0) 包裹后建索引
• 若物化视图定义含 GROUP BY a, b，索引必须覆盖全部分组列（只建 (a) 会导致比对逻辑错乱）

CONCURRENTLY 下仍要小心的干扰点

它不阻塞 SELECT，但不是零代价：

• 仍持有 SHARE UPDATE EXCLUSIVE 锁，所以对物化视图本身的 DROP、TRUNCATE 或 ALTER 会被阻塞
• 刷新期间业务写入若触发唯一键冲突（比如新数据和即将插入的行 key 相同），会报 ERROR: duplicate key value violates unique constraint
• 最后 merge 阶段若某行刚被业务 UPDATE 过，会失败并提示：could not lock updated tuple in materialized view
• 每次刷新多占一倍磁盘空间存临时副本，高频刷新（如每分钟）容易撑爆 pg_wal 或 base 目录

性能与一致性取舍的关键细节

CONCURRENTLY 实际更慢：它先全量跑一遍原始查询生成新结果集，再靠唯一索引逐行比对旧数据，做 INSERT/UPDATE/DELETE。400 万行实测，普通刷新 30s，CONCURRENTLY 常超 150s，I/O 和 CPU 明显抬高。更隐蔽的是——它不减少基表压力，原始 SELECT 仍完整执行一遍。

刷新过程中，SELECT 读到的可能是部分更新、部分未更新的混合状态。业务逻辑必须接受这种最终一致性，不能假设某次查询返回的是“某个时间点的完整快照”。