oracle物化视图不支持按分区设置不同刷新周期，因其刷新作用于整个视图；替代方案是创建多个物化视图并配合谓词分区裁剪与独立调度。
物化视图不支持按分区设置不同刷新周期
oracle 物化视图本身没有「每个分区独立配置刷新频率」的机制。你无法对 mv_tab 的 partition p1 设为每天刷新、partition p2 设为每小时刷新——这种粒度在 oracle 原生 mv 架构中不存在。
根本原因是：物化视图是逻辑对象，其刷新动作作用于整个视图（即整个结果集），底层基表分区只是存储组织方式，MV 不感知、也不控制分区级刷新调度。
实际可行的替代方案：用多个物化视图 + 分区裁剪模拟
如果业务上真有“冷热分区不同更新频率”的需求（例如最近 7 天数据高频更新、历史分区只每月校验），可拆成多个 MV，各自绑定不同查询谓词，再配合分区裁剪和独立调度：
-
mv_hot定义为SELECT * FROM t WHERE dt >= TRUNC(SYSDATE) - 7，用DBMS_MVIEW.REFRESH每 1 小时调用一次 -
mv_cold定义为SELECT * FROM t WHERE dt ，用 <code>DBMS_SCHEDULER每月 1 日凌晨执行一次DBMS_MVIEW.REFRESH('mv_cold', 'C') - 确保基表
t的dt列上有分区，且 MV 查询能触发分区裁剪（查EXPLAIN PLAN确认partition start/end非全扫） - 两个 MV 可共用一个物化视图日志（
ON t），但需注意：ROWID基础刷新模式下，mv_hot和mv_cold必须都声明为BUILD IMMEDIATE且启用FAST刷新支持
为什么不能靠 DBMS_SCHEDULER 给单个 MV “分时段刷不同分区”？
有人尝试写 PL/SQL 过程，先 ALTER MATERIALIZED VIEW mv_name MODIFY PARTITION p1 REFRESH FAST —— 这条语句根本不存在，Oracle 会报错 ORA-00922: missing or invalid option。物化视图 DDL 不接受 MODIFY PARTITION 子句。
另一个误区是：用 DBMS_MVIEW.REFRESH 的 list 参数传入分区名，例如 list => 'P1,P2'。这只会被当作 MV 名列表处理，不是分区名；若真传了分区名，会报 ORA-12003: materialized view "SCHEMA"."P1" does not exist。
真正能影响“刷哪些数据”的，只有 MV 定义里的 WHERE 条件、以及基表是否启用了物化视图日志 + 支持快速刷新的约束（如主键、外键、ROWID）。
关键检查点：避免刷新失效或全量重刷
拆多 MV 方案看似灵活，但容易因细节导致性能崩坏：
- 确认每个 MV 的
SELECT都能稳定命中目标分区：在谓词中避免函数包裹分区键（如TO_CHAR(dt, 'YYYYMMDD')），否则分区裁剪失效，每次刷新都扫全表 - 所有 MV 必须基于同一张基表的同一份物化视图日志；若分别建日志，DML 变更会被重复捕获，引发
ORA-12048: error encountered while refreshing materialized view - 使用
FAST刷新时，mv_hot和mv_cold的定义必须满足「可快速刷新子集」条件：Oracle 要求它们的查询文本是彼此的“子查询关系”，实践中建议二者谓词用互斥范围（如dt >= X和dt ），不要留空隙或重叠 - 刷新前务必查
USER_MVIEWS.REFRESH_MODE和REFRESH_METHOD，确保不是COMPLETE；一旦设成COMPLETE，哪怕你调度再精细，也是全量重建
最常被忽略的是：以为加了分区就自动优化刷新——其实 MV 刷新路径完全由查询定义和日志结构决定，跟物理分区布局没直接关系。得亲手验证执行计划和 DBA_MVIEW_ANALYSIS 里的 FAST_REFRESHABLE 字段。
