CONCURRENTLY 刷新物化视图必须存在显式创建的唯一索引，否则直接报错；索引须建在物化视图上、覆盖关键标识列、不可为表达式索引，且需处理NULL值以避免冲突。
CONCURRENTLY 刷新必须有唯一索引
没有唯一索引的物化视图，REFRESH MATERIALIZED VIEW CONCURRENTLY 会直接报错，不是卡住、不是慢，是根本执行不了。
postgresql 需要靠唯一索引（通常是主键或 UNIQUE 约束）来定位旧行、匹配新行，从而避免锁表。没它，就退化成带锁刷新，而 CONCURRENTLY 关键字本身就会被拒绝。
- 错误信息固定为：
Error: could not create unique index "pg_temp_..."或更直白的ERROR: required unique index not found - 索引字段必须覆盖查询中所有“可能用于去重”的列，通常就是 select 列表里参与 JOIN 或 WHERE 的关键标识列
- 不能用表达式索引（如
CREATE INDEX ON mv ((id::text))），必须是简单列或列组合的UNIQUE索引 - 索引需建在物化视图上，不是底层基表；即使基表有主键，MV 上也得显式创建
为什么不能用普通 B-tree 索引代替 UNIQUE 索引
因为 CONCURRENTLY 刷新依赖索引提供「确定性行匹配」：它先全量生成新数据到临时关系，再逐行用索引 Key 查旧表中对应行，做 UPDATE/INSERT/delete。普通 B-tree 不保证唯一性，会导致多行匹配、更新错乱甚至丢数据。
- 即使你手动加了
UNIQUE约束但忘了建索引，PostgreSQL 也不会自动用约束背后的隐式索引——它要求索引显式存在且可用 -
CREATE UNIQUE INDEX CONCURRENTLY可以在线建，但建完要等VACUUM或下一次ANALYZE后才被刷新逻辑识别，中间窗口期执行REFRESH ... CONCURRENTLY仍会失败 - 如果物化视图包含可空列（如
user_id Integer允许 NULL），UNIQUE索引对 NULL 值不判重，可能导致多行 NULL 冲突，建议用COALESCE(user_id, 0)包裹后建索引，或加WHERE user_id IS NOT NULL条件索引
刷新期间 DML 会不会阻塞或被阻塞
不会锁表，但有隐含冲突点：新旧数据匹配阶段依赖索引扫描，如果此时有人在相同唯一键上并发 INSERT/UPDATE/DELETE，可能触发唯一约束冲突或导致刷新中途失败。
- 典型错误：
ERROR: duplicate key value violates unique constraint—— 多发生在刷新过程中，业务写入了和即将插入的新行相同唯一键的记录 -
CONCURRENTLY刷新本身不阻塞 SELECT，也不阻塞大多数 DML，但它会在最后阶段尝试原子替换，若检测到底层数据已变（比如某行被业务 UPDATE 过），会放弃本次刷新并报错could not lock updated tuple in materialized view - 所以它不是“完全无干扰”，而是“不持锁但敏感于并发写入”；高写入场景建议避开业务高峰，或把刷新拆成小批次（靠 WHERE 分区 + 多个 MV 拆分）
CONCURRENTLY 和非 CONCURRENTLY 的性能与适用边界
并发刷新比普通刷新慢 2–5 倍，因为它要多跑一遍索引匹配 + 行级更新逻辑，而不是 truncate + insert。别为了“听起来高级”硬上 CONCURRENTLY。
- 数据量 REFRESH MATERIALIZED VIEW 更稳更快
- 需要秒级查询可用性、且 MV 查询 QPS > 100、写入低频 →
CONCURRENTLY才值得投入维护索引成本 - 如果 MV 定义里用了
ORDER BY或LIMIT，CONCURRENTLY无法保证顺序一致性，结果可能“看起来跳变”，这不是 bug，是设计使然 - 9.6 之前版本不支持
CONCURRENTLY；12+ 版本开始支持在事务块里调用，但依然禁止在函数或规则中嵌套调用
最常被忽略的一点：索引一旦建错，刷新失败时不会提示“请检查索引”，只会报一堆临时表或锁相关的模糊错误。遇到 CONCURRENTLY 报错，第一反应不该是查日志，而是立刻 d+ your_mv_name 看有没有生效的 UNIQUE 索引。