必须有唯一索引，否则REFRESH MATERIALIZED VIEW CONCURRENTLY直接报错；因PostgreSQL采用差集比对方式增量更新，需靠唯一索引列精准匹配新旧行，无索引则无法识别对应关系，故拒绝执行。
必须有唯一索引，否则 REFRESH MATERIALIZED VIEW CONCURRENTLY 直接报错，不是慢、不是卡，是根本执行不了。
CONCURRENTLY 刷新为什么强制要求唯一索引
PostgreSQL 不是重写整张表，而是用「差集比对」方式增量更新：先生成新数据到临时关系，再靠唯一索引列做 JOIN 或 EXCEPT 找出要插入、更新、删除的行。没有唯一索引，它无法判断“哪一行对应哪一行”，就拒绝执行。
典型错误信息固定为：ERROR: cannot refresh materialized view "xxx" concurrently, because it does not have a unique index 或更底层的 ERROR: required unique index not found。
- 索引必须显式创建在物化视图上（
CREATE UNIQUE INDEX ON mv_name (col)），即使底层基表有主键，MV 上也得单独建 - 索引列必须全部
NOT NULL；允许 NULL 的字段会导致多行匹配失败，可用COALESCE(col, 0)包裹后建索引 - 聚合视图中若
GROUP BY a, b，索引必须覆盖全部分组列，只建(a)会逻辑不一致 - 不能用表达式索引（如
(UPPER(name))或((id::text))），必须是简单列或列组合
哪些索引算“有效”的唯一索引
只有满足以下全部条件的索引才能被 CONCURRENTLY 识别：
- 类型是
UNIQUE或PRIMARY KEY（普通B-tree索引不行） - 状态为
VALID（刚建完可能需等一次VACUUM或ANALYZE后才生效） - 定义在物化视图本身，而非源表
- 不含函数调用、不带
WHERE条件（除非你确认刷新时能精确复现该条件）
常见误判：UNIQUE CONSTRAINT 不等于索引——约束可能没触发隐式索引创建（尤其在分区表或迁移后），必须手动执行 CREATE UNIQUE INDEX。
REFRESH CONCURRENTLY 实际执行时的干扰点
它不锁表，但不是“零干扰”：
- 刷新期间允许
SELECT，也允许大部分 DML，但若业务写入与即将插入的新行发生唯一键冲突，会直接报错：ERROR: duplicate key value violates unique constraint - 最后阶段尝试原子替换时，若某行已被业务
UPDATE过，会失败并提示：could not lock updated tuple in materialized view - 每次刷新都需额外磁盘空间存临时副本，高频率刷新（如每分钟）可能引发空间压力
- 性能上通常比普通刷新慢，因为要全量查源表 + 全量比对索引键
所以别把它当成“随便刷”，而应结合调度节奏控制：比如按时间窗口切片（WHERE created_at > now() - interval '5 min'），让单次刷新数据量可控。
如何验证 CONCURRENTLY 是否真生效
部署后必须实测，不能只看有没有报错：
- 查索引：
\d+ mv_name确认存在UNIQUE或PRIMARY KEY索引，且状态为valid - 并发测试：开两个终端，一个持续跑
SELECT COUNT(*) FROM mv_name;，另一个执行REFRESH MATERIALIZED VIEW CONCURRENTLY mv_name;，观察查询是否全程无中断、无超时 - 查运行中任务：
SELECT pid, query_start, state, query FROM pg_stat_activity WHERE query LIKE 'REFRESH%CONCURRENTLY%';（需pg_stat_activity权限）
最容易被忽略的是索引状态和 NULL 处理——建了索引却忘了 NOT NULL 约束，或用了 COALESCE 却没同步改物化视图定义里的对应字段，都会导致刷新中途失败。
