物化视图创建后查不到数据，因postgresql默认不填充数据，须显式加with data；oracle虽默认带数据，但缺select权限或查询含不支持特性会静默失败。
create materialized view 语句执行后为什么查不到数据？
物化视图创建后默认不自动填充数据，这是最常被忽略的点。postgresql（≥9.3）和 oracle 的行为不同：postgresql 要求显式指定 with data 或 with no data；oracle 默认带数据，但若基表无 select 权限或查询含不支持特性（如某些窗口函数），会静默失败。
-
CREATE MATERIALIZED VIEW mv_orders AS SELECT * FROM orders WITH DATA;—— PostgreSQL 必须加WITH DATA才能立即有数据 - Oracle 中若基表
orders未授SELECT权限给物化视图所有者，CREATE MATERIALIZED VIEW会报 ORA-12003 错误，但部分客户端可能只显示“命令完成”，实际未建成功 - MySQL 不原生支持物化视图，用
CREATE TABLE ... AS SELECT模拟时，是快照而非持续同步，这点容易误判为“物化视图”
刷新物化视图时提示 REFRESH MATERIALIZED VIEW 失败
刷新失败往往卡在锁、权限或查询兼容性上。PostgreSQL 要求刷新用户对基表有 SELECT 权限，且不能在事务块中执行 REFRESH MATERIALIZED VIEW CONCURRENTLY（该模式要求物化视图有唯一索引）。
-
REFRESH MATERIALIZED VIEW CONCURRENTLY mv_orders;报错 “could not create unique index” → 必须先在mv_orders上建唯一索引，覆盖所有行（如主键列或ctid） - Oracle 中
DBMS_MVIEW.REFRESH报 ORA-12008 → 检查物化视图日志是否缺失，或基表 DML 日志未启用（需CREATE MATERIALIZED VIEW LOG ON orders;） - 并发刷新（
CONCURRENTLY）不阻塞读，但比普通刷新慢；非并发模式会锁住物化视图整个刷新过程，应用查询可能超时
WHERE 条件写在物化视图定义里 vs 写在查询时的区别
把过滤条件放进 AS SELECT ... 定义中，能显著减少存储和刷新开销；反之，若只在查询时加 WHERE status = 'shipped'，物化视图仍存全量数据，浪费空间且刷新更慢。
- 推荐：
CREATE MATERIALIZED VIEW mv_shipped_orders AS SELECT id, amount, shipped_at FROM orders WHERE status = 'shipped' WITH DATA; - 反例：建全量视图
mv_orders，再每次SELECT * FROM mv_orders WHERE status = 'shipped'→ 物化视图体积大、刷新慢、索引效率低 - 注意：PostgreSQL 中
WHERE含 volatile 函数（如now()）会导致物化视图无法并发刷新，因为无法保证一致性快照
物化视图依赖的基表结构变更后怎么办？
基表增删列、改类型、删约束，不会自动同步到物化视图，它仍是旧结构快照。强行查询新增列会报 “column does not exist”，而删除列可能导致刷新失败。
- 修改基表后，必须手动重建物化视图：
DROP MATERIALIZED VIEW mv_orders; CREATE MATERIALIZED VIEW mv_orders AS ... WITH DATA; - Oracle 中可尝试
ALTER MATERIALIZED VIEW mv_orders COMPILE;，但仅修复编译错误，不更新列定义 - 没有自动迁移机制 —— 这不是 bug，是设计使然：物化视图本质是独立物理表，和视图（view）的动态解析完全不同
事情说清了就结束。物化视图不是“自动更新的视图”，它是带生命周期管理的物理表，建、刷、修都得手动操心。尤其别信“建完就能用”，第一次 SELECT 前务必确认 WITH DATA 和权限。
