oracle 19c物化视图不支持分区级增量刷新，fast刷新仅基于物化视图日志（mlog$_table）中记录的行级变更（dmltype$$、rowid或主键），不识别分区信息；其增量同步范围由日志内容决定，与源表是否分区无关。
oracle 19c 中物化视图本身不支持“分区级增量刷新”——它没有按分区粒度单独刷新的机制。所谓“分区增量刷新”，实际是误传或混淆概念；真正可实现的是：在分区表上创建物化视图 + 启用物化视图日志（mlog）+ 使用 fast 刷新，从而让整个物化视图只同步源表中变更过的行（无论这些行落在哪个分区）。
为什么不能对单个分区做增量刷新？
物化视图的 FAST 刷新依赖 MLOG$_<table_name></table_name> 日志表，该日志记录的是 DML 操作的逻辑变更（DMLTYPE$$、OLD_NEW$$、主键或 ROWID），不携带分区信息。Oracle 不会、也无法根据分区键值去过滤日志或限制刷新范围。即使源表是分区表（如按 sales_date 范围分区），只要某条记录被更新，日志就记一笔，FAST 刷新时就会拉取并应用该笔变更——和它在哪个分区无关。
常见误解来源：
– 看到源表有分区，以为 MV 刷新也能“只刷 P202604 分区”；
– 把分区表上的物化视图日志误认为“分区日志”；
– 混淆了“分区表的并行刷新优化”（物理读取时可并行扫描多个分区）与“按分区逻辑刷新”（不存在）。
正确启用 MLOG 并支持 FAST 刷新的 4 个硬性条件
缺一不可，否则 REFRESH FAST 会失败或自动退化为 COMPLETE：
- 源表必须有
PRIMARY KEY（推荐），或明确指定WITH ROWID（不推荐，因ROWID在分区表移动/分裂后可能失效）； - 必须在源表上创建物化视图日志，且必须包含
INCLUDING NEW VALUES（否则 UPDATE 无法被识别为增量）； - 日志中必须包含物化视图查询中涉及的所有关键列：聚合字段（如
SUM(amount)）、连接字段（如order_id）、WHERE 条件字段（如status = 'SHIPPED'）——可用DBMS_MVIEW.EXPLAIN_MVIEW验证； - 物化视图定义 SQL 必须满足 FAST 刷新的限制：不能含
SELECT *、不能有非确定性函数（如SYSDATE、ROWNUM）、聚合必须配GROUP BY主键或唯一键等。
典型安全写法示例（源表 sales_part 是按月分区的表，主键为 sale_id）：
CREATE MATERIALIZED VIEW LOG ON sales_part WITH PRIMARY KEY, SEQUENCE(sale_id, amount, status, sale_date) INCLUDING NEW VALUES;
注意：SEQUENCE 不是必须，但强烈建议加上，它通过 SEQUENCE$$ 列保证多事务并发修改时刷新顺序不乱——这对分区表尤其重要，因为不同分区的 DML 可能由不同会话发起。
刷新时如何确认是否真走 FAST 而非 COMPLETE？
别信文档，要看实际执行痕迹：
- 查
DBA_MVIEWS视图：REFRESH_METHOD为FAST仅表示“允许 FAST”，不代表每次都会用； - 执行刷新后立刻查
DBA_MVIEW_LOGS：LOG_TABLE对应的MLOG$_sales_part表中SNAPTIME$$字段若被更新为当前时间戳，说明日志已被消费，是 FAST；若MLOG$_sales_part行数归零或大幅减少，也是 FAST 的特征； - 最直接方式：在刷新前后对比
SELECT COUNT(*) FROM MLOG$_sales_part—— FAST 刷新会清空已处理的日志行；COMPLETE 则完全不碰日志表； - 开启 SQL trace（
ALTER SESSION SET EVENTS '10046 trace name context forever, level 8'），看执行计划里有没有出现MVIEW LOG SCAN步骤。
如果发现明明建了日志，但 DBMS_MVIEW.REFRESH('mv_sales', 'F') 却慢得像 COMPLETE，大概率是 EXPLAIN_MVIEW 暴露的问题没解决，比如漏了 INCLUDING NEW VALUES 或聚合字段未进日志列清单。
分区表 + MV 的一个隐蔽陷阱：主键更新导致日志膨胀
当源表是分区表且你用了 WITH PRIMARY KEY 创建日志时，注意这个行为：
– 如果业务代码执行 UPDATE sales_part SET sale_id = ... WHERE ...（即更新主键），Oracle 内部会将该操作拆成一条 D（DELETE）+ 一条 I（INSERT）记录写入日志；
– 这会导致日志行数翻倍，且新旧主键都进入日志，可能触发物化视图刷新异常（尤其带聚合时）；
– 更糟的是，如果主键更新还跨了分区（例如从 P202603 移到 P202604），ROWID 完全失效，而主键方式虽能定位，但日志体积和刷新逻辑复杂度陡增。
所以，在分区表上启用 MV 日志前，务必确认：
– 主键是否真的不可更新（绝大多数场景应如此）；
– 若业务确有主键变更需求，宁可放弃 FAST，改用 REFRESH FORCE + 定期 COMPLETE，也比让日志失控强。
真正需要“分区级控制”的场景，应转向其他机制：比如用 DBMS_SCHEDULER 按分区名拼接子查询做定制化刷新，或直接用 Oracle GoldenGate / OGG 做分区级 CDC 同步——物化视图不是为此设计的。
