物化视图比普通视图多占用真实磁盘空间，普通视图仅存元数据（几十字节），而物化视图生成物理数据文件，大小等同于其查询结果（如1GB），还需额外考虑索引、日志及快照冗余等配套开销。
物化视图比普通视图多占用真实磁盘空间，普通视图几乎不占存储。这不是理论差异，而是物理事实——物化视图在 PostgreSQL 或 Oracle 中创建后，会立即生成一个带 relfilenode 的物理关系，就像一张表；普通视图则只在 pg_views 或 USER_VIEWS 里存一条文本记录。
普通视图的存储开销：仅元数据，无数据文件
普通视图（CREATE VIEW）本质是保存在系统目录中的 SQL 字符串。它不分配数据块，不写 WAL，也不触发任何物理 I/O。
- 查看存储：执行
\d+ my_view在 psql 中只会显示“View”，没有 size 字段 - 查系统表：
SELECT * FROM pg_class WHERE relname = 'my_view'返回空或无relfilenode - 即使底层表有 1TB 数据，视图定义本身通常只占几十字节
物化视图的存储开销：等同于一张表
PostgreSQL 的 CREATE MATERIALIZED VIEW 会调用内部函数创建一个带存储的 RELKIND_MATVIEW 对象，其数据文件与普通表完全一致。
- 物理大小可查：
SELECT pg_size_pretty(pg_total_relation_size('my_mv')) - 它会产生
pg_class.relpages、pg_class.reltuples等统计项 - 如果源查询返回 500 万行 × 200 字节/行 ≈ 1GB，那物化视图就真占 1GB（不含索引）
- Oracle 中还会额外占用
MATERIALIZED_VIEW_LOG空间（如启用快速刷新）
存储成本容易被低估的三个点
很多人只算“物化视图本身”，却漏掉配套开销：
- 索引：为加速查询常建索引，
CREATE INDEX ON my_mv(user_id)会再增 30%~100% 存储 - 日志：PostgreSQL 刷新时走 INSERT/DELETE，WAL 日志量显著上升；Oracle 快速刷新依赖物化视图日志（
MLOG$表） - 快照冗余：某些数据库（如 Doris 异步 MV）会保留多个版本快照，实际占用是单次结果的 N 倍
真正决定要不要用物化视图的，往往不是“能不能提速”，而是“这张预计算表的存储代价，是否低于它省下来的每次查询 CPU + IO 成本”。尤其当源表每天只增几千行，但物化视图要存全部历史聚合结果时，空间可能滚雪球式增长。
