物化视图将查询结果物理存储于磁盘，本质是一张只读表；普通视图仅保存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 have 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”，不会自动溯源到最底层。
