物化视图提速必须启用ENABLE QUERY REWRITE且权限、结构、索引、统计信息缺一不可，否则查询重写失败；建索引、收集统计信息、合理刷新策略是保障实效性的关键。
普通视图查得慢，不是因为写法有问题，而是它每次都在实时执行底层 SQL。想提速，就得让 Oracle 别每次都算——物化视图 + 查询重写是唯一直接有效的路径，但必须按条件配齐，缺一不可。
物化视图创建时漏掉 ENABLE QUERY REWRITE 就等于白建
这是最常被跳过的一步。CREATE MATERIALIZED VIEW 语句里不显式加上 ENABLE QUERY REWRITE，哪怕结构完全匹配原查询，优化器也绝不会考虑用它。
- 错误写法：
CREATE MATERIALIZED VIEW mv_sales_sum AS SELECT dept_id, SUM(sales) FROM sales GROUP BY dept_id - 正确写法：
CREATE MATERIALIZED VIEW mv_sales_sum ENABLE QUERY REWRITE AS SELECT dept_id, SUM(sales) FROM sales GROUP BY dept_id - 该子句不能后期添加，建完就定死了；如果忘了，只能 DROP 后重建
- 建之前确认用户有
QUERY REWRITE权限，否则 DDL 会报ORA-30372: fine grain access policy conflicts with materialized view
EXPLAIN PLAN 看不到物化视图名？别猜，用 DBMS_MVIEW.EXPLAIN_REWRITE 查真实原因
执行 EXPLAIN PLAN FOR ... 后查 PLAN_TABLE，发现 OBJECT_NAME 还是基表名，不代表配置失败——可能是语义不匹配、状态过期或权限未生效。真正能定位问题的是 DBMS_MVIEW.EXPLAIN_REWRITE。
- 先运行
@?/rdbms/admin/utlxrw.sql（或UTLXRWY.SQL）建解释表REWRITE_TABLE - 执行：
EXEC DBMS_MVIEW.EXPLAIN_REWRITE('SELECT dept_id, SUM(sales) FROM sales_v GROUP BY dept_id', 'MV_SALES_SUM') - 查结果：
SELECT message FROM rewrite_table WHERE rewrite_reason = ''FAILED'' - 典型输出：
Grouping column missing（物化视图没包含查询里的GROUP BY列）、No suitable materialized view found（名字或 owner 不对）、Stale data（DBA_MVIEWS.STALENESS = ''STALE''）
带聚合的视图必须满足分组列严格等价，且不能缺维度主键
比如你有一个视图 sales_summary_v： SELECT t.year, t.quarter, SUM(s.amount) FROM sales s JOIN time_dim t ON s.time_id = t.time_id GROUP BY t.year, t.quarter，那对应的物化视图必须：
- SELECT 列顺序和别名完全一致（
SUM(s.amount)不能写成SUM(amount)，也不能加AS total而查询里没写） - GROUP BY 列必须完整出现在物化视图定义中，且类型一致（
t.year是 NUMBER 就不能用EXTRACT(YEAR FROM s.time_id)替代） -
time_dim表必须有启用的主键约束，且物化视图创建前执行过ALTER TABLE time_dim ENABLE RELY PRIMARY KEY（尤其当QUERY_REWRITE_INTEGRITY = ENFORCED时） - 避免在物化视图定义中用
TO_CHAR(t.time_id, ''YYYY-Q'')这类表达式，它会阻断重写；改用EXTRACT(YEAR FROM t.time_id)和EXTRACT(QUARTER FROM t.time_id)
物化视图建完不建索引，跟没建一样
物化视图本质是一张物理表（对象类型为 MATERIALIZED VIEW，底层存储名类似 WM$12345），但它不会继承任何原表索引，也不会自动生成索引。WHERE 过滤、JOIN 条件、ORDER BY 都依赖你手动建的索引。
- 高频过滤字段优先建复合索引，顺序按选择性从高到低：例如常查
WHERE region = ''CN'' AND sale_date >= DATE ''2024-01-01''，就建CREATE INDEX idx_mv_reg_date ON mv_sales (region, sale_date) - 低基数维度列（如
status、product_category）适合位图索引：CREATE BITMAP INDEX idx_mv_status ON mv_sales (status) - 聚合物化视图中用于 GROUP BY 的列，必须出现在索引前列，否则排序/去重仍可能走全表扫描
- 刷新后记得收集统计信息：
EXEC DBMS_STATS.GATHER_TABLE_STATS(USER, ''MV_SALES'')，否则优化器成本估算失真，可能放弃重写
真正难的从来不是建物化视图，而是让它的数据新鲜度、刷新开销、查询匹配精度三者平衡。比如多表连接+聚合的物化视图，FAST 刷新往往不可用，COMPLETE 刷新又太重——这时与其强求“实时”，不如接受“T+1”并把调度窗口卡死在凌晨低峰期，再配合分区剪枝和位图索引压住查询延迟。
