在PostgreSQL 16中，即便加上了CONCURRENTLY，仍会报“does not ha ve a unique index”错误，这是为什么呢？原因在于命令入口会校验硬性前提：必须明确地在物化视图上创建一个VALID唯一索引，这个索引要覆盖所有的分组列，并且所有列都不能为NULL，也不能有函数表达式。只要缺了其中任何一个条件，就会直接拒绝执行，根本不会进入刷新阶段。

PostgreSQL 16 不支持真正的增量刷新，REFRESH MATERIALIZED VIEW CONCURRENTLY 仍是全量执行 + 差集比对，但能避免读锁；它能跑起来的唯一前提是：物化视图上必须有满足全部硬性条件的唯一索引。

为什么加了 CONCURRENTLY 还报 “does not ha ve a unique index”

这可不是配置疏漏或者权限不足的问题，而是PostgreSQL 16在命令入口处就进行了严格的校验：只要没有索引，就会直接被拒之门外，根本不会进入执行阶段。其错误信息固定为：ERROR: cannot refresh materialized view "xxx" concurrently, because it does not ha ve a unique index。

• 索引必须显式建在物化视图上，CREATE UNIQUE INDEX ON my_mv (id) —— 源表有主键、或约束带唯一性，都不算数
• 所有索引列必须 NOT NULL；如果字段允许 NULL，得用 COALESCE(col, 0) 或类似兜底后再建索引
• 聚合类视图（如含 GROUP BY tenant_id, event_type）必须把全部分组列放进索引，顺序也要一致，(tenant_id, event_type) 不能写成 (event_type, tenant_id)
• 刚建完索引可能状态是 INVALID，需执行一次 VACUUM my_mv 或 ANALYZE my_mv 才被识别
• 表达式索引（如 (UPPER(name))）、带 WHERE 条件的索引、函数索引，一律不被接受

CONCURRENTLY 刷新失败的常见真实原因

即使索引建对了，刷新仍可能中途失败，且失败后物化视图处于“部分更新”状态 —— 旧数据没全删、新数据没全写，不可靠。

• 业务写入与新数据产生唯一键冲突：ERROR: duplicate key value violates unique constraint（比如新数据要插 order_id = 123，但业务刚好 INSERT 了同 ID 的行）
• 某行在 merge 阶段前被业务 UPDATE 过：could not lock updated tuple in materialized view
• 物化视图刚创建、还没填充过（即处于 WITH NO DATA 状态），CONCURRENTLY 会直接拒绝 —— 必须先用普通 REFRESH MATERIALIZED VIEW my_mv 填一次
• 定义中含不可重放表达式：now()、random()、CURRENT_USER，或未配 ORDER BY 的 DISTINCT ON / 窗口函数，导致新旧结果无法精确比对

性能和资源上容易被低估的开销

并发刷新不是“更快”，而是“可读”，实际代价往往更高。

• 每次都要全量扫描源表 + 全量执行原始查询 + 两次索引扫描（新旧数据各一次）+ 差集计算，实测 400 万行下比普通刷新慢 3–4 倍
• 临时副本需额外磁盘空间，高频刷新（如每分钟一次）极易触发 no space left on device
• 它不阻塞 SELECT，但会阻塞某些 DML：比如对正在刷新的 MV 执行 UPDATE 或 DELETE 可能被锁住
• 真正省时间的地方不在刷新命令本身，而在物化视图定义：去掉 DISTINCT ON、避免无序 json_agg、让聚合字段类型和 WHERE 条件严格一致（比如别用 EXTRACT(YEAR FROM ts) = 2024，该写 EXTRACT(YEAR FROM ts)::int = 2024）

想“增量”，只能自己控范围

PostgreSQL 内核不提供基于 WAL 或变更日志的增量能力。CONCURRENTLY 不是增量，只是“全量查 + 全量比 + 差异写”。真要减少数据量，得靠外部逻辑：

• 手动维护位点：建一张 matview_refresh_state 表存上次最大 updated_at，刷新 SQL 中加 WHERE updated_at >
• 用 pg_matview 扩展：本质是把 MV 当普通表 + 触发器捕获变更 + 手写 INSERT ON CONFLICT，它不自动推导变化行，只帮你搭个壳
• 前提是你有可靠单调递增字段（如自增 ID、严格递增时间戳），否则边界判定会出错

最常被忽略的一点：索引结构必须在建物化视图时就设计好，而不是等 CONCURRENTLY 报错才回头改。一旦 MV 数据量上去，重建索引或改结构的成本远高于初期多花十分钟选对主键语义。

《夸克》非常好用的免费AI浏览器

下载APP查看