根本原因是基表或物化视图日志统计信息过期缺失，导致Oracle生成低效执行计划，如全表扫描MLOG$_xxx或错误连接方式；刷新前应收集分区级统计信息并验证FAST_REFRESHABLE状态。
物化视图刷新时执行计划走错，为什么 DBMS_MVIEW.REFRESH 会变慢
根本原因常是基表（尤其是分区表）的统计信息过期或缺失，导致 oracle 在刷新过程中生成低效执行计划——比如本该走分区剪枝，却全表扫描日志表 mlog$_xxx；或者对物化视图日志做嵌套循环连接，而实际应走哈希连接。
实操建议：
- 刷新前强制收集基表和物化视图日志的统计信息：
DBMS_STATS.GATHER_TABLE_STATS，特别注意带上GRANULARITY => 'PARTITION'参数，否则分区级统计可能为空 - 用
EXPLAIN PLAN FOR EXECUTE IMMEDIATE 'BEGIN DBMS_MVIEW.REFRESH(...); END;'捕获真实刷新语句的执行计划，而非只查物化视图本身的 SELECT 计划 - 检查
USER_MVIEWS视图中FAST_REFRESHABLE列是否为YES，若为NO或DIRLOAD_DML，说明快速刷新已退化为完全刷新，执行计划必然不同
CREATE MATERIALIZED VIEW 里加 PARTITION BY RANGE 有没有用
有用，但仅当物化视图本身定义含时间/序列类列且你主动控制其分区策略时才生效。Oracle 不会自动继承基表的分区结构，也不会根据基表分区自动拆分物化视图数据。
常见误区：
- 以为建在分区表上的物化视图“天然”分区——实际默认仍是单段堆表，
USER_TAB_PARTITIONS查不到任何分区记录 - 忽略物化视图分区键必须与查询重写或刷新逻辑兼容：例如按
TRUNC(order_date, 'MM')分区，但刷新时 WHERE 条件用的是order_date >= DATE '2026-04-01'，可能导致分区剪枝失效 - 未同步维护物化视图分区的本地索引——
CREATE INDEX ... LOCAL必须显式声明，否则全局索引会成为刷新瓶颈
查询重写（Query Rewrite）不触发，EXPLAIN PLAN 里看不到物化视图访问
不是执行计划问题，而是前提条件未满足。Oracle 的查询重写是硬性校验机制，缺一不可。
关键检查点：
-
QUERY_REWRITE_ENABLED = TRUE（实例级）且用户有QUERY REWRITE权限，二者缺一不可 - 物化视图创建时明确指定
ENABLE QUERY REWRITE，而不是靠 ALTER 修改——后者不会补全内部重写依赖关系 - 原始 SQL 中的表别名、函数包装（如
TO_CHAR(date_col)）、隐式类型转换，都会破坏重写匹配；建议用DBMS_MVIEW.EXPLAIN_REWRITE直接诊断失败原因 - 基表和物化视图的统计信息版本不一致（比如基表刚 ANALYZE 过，物化视图没更新），会导致代价估算失真，Oracle 主动放弃重写
分区表 + 物化视图组合下，FAST REFRESH 为什么仍全量扫日志
因为物化视图日志（MLOG$）本身没分区，且默认不支持分区裁剪。即使基表按月分区，日志表仍是单一大表，FAST REFRESH 仍需扫描全部变更记录再过滤。
缓解方案：
- 限制日志保留窗口：通过
DBMS_MVIEW.PURGE_LOG定期清理旧日志，避免MLOG$膨胀成性能黑洞 - 避免在高并发 DML 场景下使用基于 ROWID 的快速刷新——它依赖
MLOG$中的SEQUENCE$$排序，极易因日志碎片化导致排序开销飙升 - 对超大分区表，考虑改用
ON COMMIT+FAST刷新，配合应用层控制事务粒度，比ON DEMAND批量刷更可控
执行计划只是表象，真正卡住性能的，往往是物化视图日志的物理组织方式、统计信息的颗粒度偏差，以及查询重写引擎对 SQL 文本的字面匹配要求——这些细节不手动验证，光看 EXPLAIN PLAN 输出容易误判。
