物化视图默认只读，FOR UPDATE 无效；更新只能通过 REFRESH 实现，支持 CONCURRENTLY（需唯一索引）和普通刷新；其本质是无 WAL、无行版本的快照表，不支持 DML；高鲜度需求场景应选替代方案。
物化视图默认就是只读的，FOR UPDATE 不起作用
postgresql 12+ 支持物化视图，但它的 refresh 机制决定了它本质上不可直接更新。哪怕你写 create materialized view ... for update，这个子句会被忽略——语法上不报错，但实际无任何效果，也不会让视图变可写。for update 是普通视图（view）里用于定义规则的子句，在物化视图中纯属冗余。常见错误是复制了普通视图的写法，以为能借此启用行级锁或更新能力，结果发现 update my_mv set ... 直接报错：error: cannot update materialized view。
实操建议：
- 删掉物化视图 DDL 中的
FOR UPDATE，它不被解析也不影响行为 - 如果真需要“类更新”语义，必须走
REFRESH MATERIALIZED VIEW全量重算，而不是 DML - 注意：某些旧版文档或迁移脚本残留了该子句，检查
\d+ my_mv输出，确认没有误信“已启用更新支持”
想“更新”物化视图？只有 REFRESH 这一条路
物化视图的数据是快照，不是实时映射。所谓“更新”，本质是用新查询结果覆盖旧数据。PostgreSQL 提供两种刷新方式：REFRESH MATERIALIZED VIEW CONCURRENTLY（加锁少，但要求原视图有唯一索引）和普通 REFRESH（阻塞查询，但无索引要求）。性能差异明显：并发刷新允许读操作继续，但会慢一点；非并发刷新快，但期间 SELECT 会被挂起。
实操建议：
- 生产环境优先加唯一索引（如
CREATE UNIQUE INDEX ON my_mv (id)），再用CONCURRENTLY避免查询中断 - 别在事务块里执行
REFRESH—— 它本身是事务性操作，嵌套会导致锁升级或死锁 - 频繁刷新（如每分钟）要考虑底层表写入压力；物化视图刷新会重新执行定义查询，IO 和 CPU 开销与原始查询一致
为什么不能像普通表一样增删改？根本限制在存储结构
物化视图底层不存 WAL 日志，也不维护行版本（xmin/xmax），更没有触发器或规则系统支持写入路由。它本质是一张带元数据标记的普通表（pg_class.relkind = 'm'），但 PostgreSQL 明确禁止对 relkind = 'm' 的关系执行 INSERT/UPDATE/DELETE。试图绕过（比如直接 INSERT INTO pg_class 改类型）会破坏系统目录一致性，实例可能无法启动。
实操建议：
- 不要尝试用
ALTER TABLE my_mv RENAME TO ...后当普通表用——元数据仍标记为物化视图，后续REFRESH会失败 - 若需临时可写中间表，显式建一张普通表（
CREATE TABLE），再用INSERT INTO ... SELECT手动同步，而非依赖物化视图机制 - 注意：物化视图不支持分区、不支持
INHERITS，这些限制都源于其只读快照定位
替代方案：哪些场景其实不该用物化视图
如果业务逻辑反复要求“修改某字段后立即可见”，说明数据新鲜度要求高，而物化视图的刷新延迟（哪怕秒级）和全量覆盖特性反而成了瓶颈。这时更合适的可能是：带索引的普通视图 + 足够优化的查询；或使用逻辑复制 + 本地只读副本表；甚至考虑 pg_cron 定时跑 INSERT ... ON CONFLICT 增量合并。
实操建议：
- 检查物化视图定义查询是否含不稳定函数（如
now(),random()）——这会导致每次REFRESH结果不同，违背“确定性快照”初衷 - 如果底层表更新极少（如配置表、维度表），物化视图很合适；但如果源表每秒写入百行，就该怀疑是否误用了技术方案
- 一个容易被忽略的点：物化视图无法响应底层表的
TRUNCATE，刷新后数据消失但不会报错，监控上容易漏掉这类静默失效
