分批次刷新仅对物化视图完全刷新（complete）有效，不能加速快速刷新（fast）；因物化视图本身不分区，fast依赖的日志不记录分区信息，而complete需手动拆分分区查询并重建多个物化视图。
分批次刷新不能直接加速多分区表物化视图的快速刷新（fast），它只对完全刷新（complete）有效，且必须手动控制。oracle 的 dbms_mview.refresh 本身不支持“按分区刷物化视图”——物化视图本身不分区，只有基表（如分区表）才分；所谓“分批次”，实际是绕过物化视图机制，靠人工拆解基表分区 + 构造子查询 + 分批重建局部物化视图，成本高、风险大，仅在极端场景下权衡使用。
为什么不能对物化视图本身按分区刷新
物化视图是逻辑对象，没有物理分区概念。即使基表 sales_part 按月分区，物化视图 mv_sales_monthly 仍是单个段（segment），其刷新行为由刷新类型决定：
-
FAST刷新依赖物化视图日志（mlog$_xxx），日志记录的是 ROWID 或主键变更，不带分区信息；Oracle 内部按日志条目顺序处理，无法指定“只刷 P202603 分区的变更” -
COMPLETE刷新会重跑整个 SELECT 查询，若查询中没加分区裁剪条件（如WHERE dt >= DATE '2026-03-01'），就必然全表扫描所有分区，无法跳过 -
FORCE是自动选 FAST 或 COMPLETE，不受人工分区干预
哪些场景下可以“伪分批”完成 COMPLETE 刷新
当物化视图定义含聚合、GROUP BY 或复杂 JOIN，导致无法建 FAST 日志时，只能走 COMPLETE 刷新；此时可通过改写查询 + 分批提交，降低单次锁表时间和 UNDO 压力：
- 确保基表有分区键字段（如
sale_date），且该字段在物化视图 SELECT 列表中显式出现 - 把原物化视图拆成多个“按分区范围定义”的物化视图（例如
mv_sales_202603、mv_sales_202604），每个只查一个分区：SELECT ... FROM sales_part PARTITION (SYS_P123) ... - 用 PL/SQL 循环调用
DBMS_MVIEW.REFRESH，每次只刷一个物化视图，并加atomic_refresh => FALSE避免隐式 TRUNCATE 锁全表 - 注意：这种方式需额外维护 N 个物化视图对象，查询时需 UNION ALL 或改写应用层 SQL，管理成本陡增
真正能提升多分区表 FAST 刷新效率的关键点
与其折腾“分批”，不如夯实 FAST 刷新基础，让增量变更真正轻量：
- 基表必须建
WITH ROWID类型的物化视图日志（而非PRIMARY KEY），因为分区表主键可能跨分区失效，而 ROWID 始终唯一可定位 - 创建日志时务必加
INCLUDING NEW VALUES，否则 UPDATE 后旧值丢失，FAST 刷新会失败或数据错乱 - 避免在物化视图定义中使用
SYSDATE、ROWNUM、分析函数（如RANK()）、LONG 类型字段——这些直接禁用 FAST - 检查
USER_MVIEWS视图中FAST_REFRESHABLE列是否为YES，不是就说明定义不满足条件，强行REFRESH FAST会被降级为 COMPLETE
最常被忽略的一点：多分区表上建物化视图日志后，DBMS_MVIEW.EXPLAIN_MVIEW 返回的 capable_name = 'REFRESH_FAST_AFTER_INSERT' 等能力项，必须每项都为 YES 才算真正就绪；少一个，下次 INSERT 就可能触发 COMPLETE 刷新——这种隐式降级不会报错，但性能雪崩。
