物化视图必须严格匹配查询的GROUP BY和WHERE组合才能重写生效。需按高频报表SQL反推建专用MV，避免全维度组合；时间字段慎用函数；须验证OBJECT_NAME是否为MV名、REWRITE_MECHANISM为TEXT_MATCH，并显式分区与增量刷新。
物化视图必须显式覆盖高频查询的GROUP BY和WHERE组合
物化视图不会“智能适配”多维查询，它只按你写的select语句固化结果。如果你的报表常查where region = 'cn' and time_id >= date'2024-01-01' and product_category in ('a','b')，而物化视图只定义了group by time_id，那99%概率不命中重写。
实操建议：
- 不要试图建一个“全维度”物化视图——
GROUP BY region, time_id, product_category, channel会导致存储爆炸、刷新变慢，且低频组合浪费资源 - 按实际报表SQL反推：提取BI工具里Top 5慢查询的
GROUP BY字段+常用WHERE过滤列，每个组合建一个专用MV - 对时间字段慎用函数：避免
TO_CHAR(time_id, 'YYYY-MM')，改用TRUNC(time_id, 'MM')或EXTRACT(YEAR FROM time_id), EXTRACT(MONTH FROM time_id)，否则重写失败
必须验证QUERY REWRITE是否真正生效，不能只看执行计划里有没有MV名字
EXPLAIN PLAN FOR SELECT ...输出里出现MV REWRITE只是第一步；真正关键的是后续操作是否落在物化视图上。常见假阳性：计划显示TABLE ACCESS FULL，但对象名却是基表，说明重写没成功。
实操建议：
- 执行
EXPLAIN PLAN后，查PLAN_TABLE中OBJECT_NAME列是否为你的物化视图名（如mv_sales_daily_region_prod） - 用
DBMS_MVIEW.EXPLAIN_REWRITE做精准诊断：传入原始SQL和MV名，看返回的REWRITE_MECHANISM是TEXT_MATCH还是GENERAL，前者才表示结构级匹配 - 确认会话级开关已打开：
ALTER SESSION SET QUERY_REWRITE_ENABLED = TRUE，且用户有QUERY REWRITE权限
分区表上的物化视图要主动分区，别指望Oracle自动继承
基表是RANGE-LIST复合分区（比如按time_id范围+region列表），物化视图默认就是单一分区表。这意味着按月查询时无法利用分区裁剪，全表扫描MV反而比查基表还慢。
实操建议：
- 创建时显式加
PARTITION BY RANGE (time_id)，与基表时间分区策略对齐 - 避免在MV定义中用
TRUNC(time_id,'MM')作为分组字段——这会让Oracle无法关联到物理分区，改用原生time_id列分组+分区 - 刷新策略选
REFRESH FAST ON DEMAND，配合DBMS_MVIEW.REFRESH_FAST_AFTER_INSERT按分区增量刷新，比全量快一个数量级
多个物化视图无法自动拼接，得靠业务层或物化视图嵌套
你建了mv_by_time和mv_by_region，但查询同时带时间+区域条件时，Oracle不会把两个MV结果JOIN起来。它只尝试单个MV匹配，失败就回退基表。
实操建议：
- 放弃“拆分MV”思路，直接建组合维度MV：如
mv_sales_time_region含GROUP BY TRUNC(time_id,'DD'), region - 若维度实在太多，可用嵌套MV：先建底层细粒度MV（如按天+产品），再在其上建聚合层MV（如按月+大区），用
ENABLE QUERY REWRITE让上层自动重写到底层 - 禁用
ON COMMIT刷新——多MV场景下极易引发锁等待，统一走ON DEMAND+ 调度任务批量刷新
EXPLAIN PLAN里那个“MV”只是优化器画的大饼，没进OBJECT_NAME字段就不算数。
