物化视图查询重写生效需同时满足query_rewrite_enabled=true、用户具备query rewrite权限、物化视图启用enable query rewrite且build immediate，缺一不可；语义不匹配、分区键不一致、日志缺失关键字段或snaptime$$滞后均会导致重写失败或数据陈旧。
物化视图能显著缩短olap响应时间，但前提是它得被真正用起来——不是建完就完事，而是要让查询重写（query rewrite）生效、让刷新不拖后腿、让执行计划走对路径。
为什么EXPLAIN PLAN里还是走基表，而不是物化视图？
最常见的情况是查询重写根本没触发。Oracle 19c默认不会自动把SQL重写成查物化视图，哪怕物化视图结构完全匹配。
-
QUERY_REWRITE_ENABLED必须设为TRUE（不是FORCE），且用户要有QUERY REWRITE权限 - 物化视图必须启用
BUILD IMMEDIATE和ENABLE QUERY REWRITE，缺一不可 - 如果物化视图基于视图，而该视图含
UNION ALL，重写器直接跳过——得把UNION ALL逻辑“平铺”进物化视图定义本身，不能套一层视图 - 用
DBMS_MVIEW.EXPLAIN_REWRITE检查具体失败原因，返回UNREWRITTEN通常意味着语义不匹配或约束缺失
物化视图建了，但OLAP查询还是慢，是不是没走分区裁剪？
是。分区表上的物化视图默认是单段结构，即使基表按 SALES_DATE 分区，物化视图也不会自动继承——查2026年6月数据，照样扫全量。
- 必须显式声明
PARTITION BY RANGE(sales_month)，且分区键表达式、边界值、粒度（如VALUES LESS THAN (DATE '2026-07-01')）要和基表严格一致 - 若基表用
TRUNC(order_date, 'MM')作为分区键，物化视图也得用同样表达式，不能只写order_date - 建完后查
USER_TAB_PARTITIONS确认物化视图真有多个分区，而非只有一个DEFAULT分区
快速刷新总失败，导致物化视图数据陈旧怎么办？
快速刷新失败，物化视图就退化成静态快照，OLAP结果越来越不准，用户自然觉得“变慢”——其实是数据不对了。
- 物化视图日志必须包含所有 SELECT 列 +
ROWID+SEQUENCE+INCLUDING NEW VALUES（DELETE操作依赖它） - 基表若有分区键表达式（如
TO_CHAR(sale_time, 'YYYYMM')），日志里也得用相同表达式ADD COLUMN，不能只加原列 - 大规模
DELETE后，SNAPTIME$$不会自动更新，需手动推进：执行一次DBMS_MVIEW.REFRESH('mv_sales', method => 'F')，哪怕失败也要强制更新时间戳 - 刷新后立刻跑
DBMS_STATS.GATHER_TABLE_STATS，否则优化器可能因统计信息过期而放弃使用物化视图
真正卡住OLAP性能的，往往不是物化视图建得够不够多，而是日志字段漏一个、分区键差一天、SNAPTIME$$ 滞后三天——这些细节不盯紧，再大的物化视图也只是一张静态表。
