必须先建唯一索引，否则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 - 索引必须显式创建在物化视图上（
CREATE UNIQUE INDEX ON mv_name (col)），即使源表有主键，MV 上也得单独建 - 索引列必须全部
NOT NULL；允许NULL的字段会导致多行匹配失败，可用COALESCE(col, 0)包裹后建索引 - 聚合视图中若
GROUP BY a, b，索引必须覆盖全部分组列，只建(a)会逻辑不一致 - 不能用表达式索引（如
(UPPER(name))或((id::text))），必须是简单列或列组合
REFRESH MATERIALIZED VIEW CONCURRENTLY 的实际限制
它不锁表，但不是“零干扰”：
- 刷新期间允许
SELECT，也允许大部分 DML，但如果业务写入与即将插入的新行发生唯一键冲突，会直接报错：ERROR: duplicate key value violates unique constraint - 最后阶段尝试原子替换时，若某行已被业务
UPDATE过，会失败并提示：could not lock updated tuple in materialized view - 每次刷新都需额外磁盘空间存临时副本，高频率刷新（如每分钟）可能引发空间压力
- 性能上通常比普通刷新慢，因为要全量查源表 + 差集计算 + 两次索引扫描
- 不能在事务块里使用
CONCURRENTLY版本
首次刷新必须用非并发模式
即使索引建对了、字段非空、列全覆盖，如果物化视图刚创建还没填充过数据（即处于 WITH NO DATA 状态），CONCURRENTLY 也会拒绝执行——必须先用普通刷新填一次：
REFRESH MATERIALIZED VIEW mv_sales_summary;
之后才能安全执行：
REFRESH MATERIALIZED VIEW CONCURRENTLY mv_sales_summary;
- 普通刷新失败时，物化视图内容不变，状态可预测；重试安全
-
CONCURRENTLY刷新失败时，可能已部分更新（插入了新行但没删完旧行），导致数据重复或缺失；必须手动清理或重建 - 别指望它是“增量”——它只是避免锁表，背后仍是全量
SELECT+ 全量比对
定时调度建议用 pg_cron，不是 shell 脚本
pg_cron 是最贴合内核的调度方案，避免网络延迟和身份认证问题，但安装后必须确认：
-
shared_preload_libraries = 'pg_cron'已写入postgresql.conf且服务已重启 - 执行
cron.schedule()的用户被授予权限：GRANT USAGE ON SCHEMA cron TO your_user - 默认 job 在
postgres数据库下运行；若物化视图在其他库，需用全限定名：database_name.schema_name.mv_name - 避免用
*通配时间表达式（如'*/5 * * * *'），高并发下易触发多个实例；建议用固定分钟数，例如'5,10,15,20,25,30,35,40,45,50,55 * * * *'
真正容易被忽略的是：所有这些配置都成立的前提下，CONCURRENTLY 仍要求物化视图定义中不能含 DISTINCT ON 或窗口函数——哪怕有唯一索引，也可能直接不支持。
