物化视图将查询结果物理存储于磁盘，本质是一张只读表；普通视图仅保存SELECT语句，每次查询均重执行底层SQL，不占用存储空间但性能开销大。

物化视图和普通视图的数据存储方式完全不同

普通视图不存储数据，仅保存一条 SELECT 语句。每次执行 SELECT * FROM my_view 时，PostgreSQL 都会将视图定义“展开”，然后重新执行原始查询。而物化视图则是在磁盘上真正创建了一张表，将 SELECT 的结果集完整地写入其中，其本质就是一张只读的物理表。

这意味着：普通视图零空间占用，但查询开销完全取决于底层 SQL 复杂度；物化视图要占真实磁盘空间（大小 ≈ 查询结果行数 × 字段宽度），但后续所有查询都绕过计算，直接走存储层。

刷新机制是物化视图的核心操作点

普通视图根本不存在“刷新”这回事——它没有数据可刷。而物化视图必须显式调用 REFRESH MATERIALIZED VIEW 才能更新内容，否则永远停留在创建或上次刷新时的状态。

• REFRESH MATERIALIZED VIEW mv_name：锁住整个视图，阻塞并发查询，适合低流量时段
• REFRESH MATERIALIZED VIEW CONCURRENTLY mv_name：允许查询同时进行，但要求物化视图已有唯一索引（比如主键或 UNIQUE 约束），否则报错 ERROR: cannot refresh materialized view "xxx" concurrently because it does not ha ve a unique index
• PostgreSQL 本身不提供自动刷新，得靠外部调度（如 pg_cron 扩展或系统 cron）来定时执行刷新命令

索引和查询性能差异非常实际

你不能在普通视图上建索引，因为没地方存——索引必须落在物理结构上。但物化视图可以像普通表一样加 CREATE INDEX ON mv_name (col)，这对聚合结果或宽表特别有用。

性能表现上：如果一个视图涉及 5 张大表 JOIN + GROUP BY + 窗口函数，普通视图每次查都要重算；物化视图只要刷新完成，查起来和查一张本地表几乎无差别。但要注意——如果基表每分钟都在变，而你每小时才刷新一次，那查到的就是最多 60 分钟前的快照。

别忽略物化视图的不可写性和依赖风险

物化视图是不支持 INSERT/UPDATE/DELETE 这些操作的，要是强行去写，就会报 ERROR: cannot insert into materialized view 这样的错。而且它也不会自动去感知基表的结构变更。比方说，如果把源表的字段给删了，刷新的时候就会直接失败；要是加了新字段但没去改物化视图的定义，那新字段就不会出现在物化视图里。

真正容易被忽略的是依赖链断裂风险——比如物化视图基于视图 A，而视图 A 又依赖表 B；一旦表 B 被重命名或权限被撤，REFRESH 就会失败，且错误信息往往只提示“relation not found”，不会自动溯源到最底层。

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

下载APP查看