oracle 19c中分区表物化视图支持快速刷新的前提是：基表必须创建含with sequence、rowid及including new values的物化视图日志，且物化视图定义不能含非确定性函数、select*等不支持快速刷新的结构。
物化视图快速刷新对分区表的支持前提
Oracle 19c 中，物化视图要对分区表支持快速刷新（FAST REFRESH），核心限制不在“分区表本身”，而在于基表是否满足物化视图日志（MLOG$）的结构要求 + 刷新策略是否匹配 DML 模式。分区表只是基表的一种物理组织形式，Oracle 不因“分区”额外放宽或收紧快速刷新条件。
关键判断点：
- 基表（即被物化视图 SELECT 的表）必须已创建
MATERIALIZED VIEW LOG，且日志包含WITH ROWID或WITH PRIMARY KEY - 若基表是分区表，日志必须建在整个表上（不能只建在某个分区），且日志类型需支持
SEQUENCE（尤其涉及更新操作时） - 物化视图定义中不能含不支持快速刷新的构造，比如：
SELECT *、聚合函数未配GROUP BY、子查询含非确定性函数（SYSDATE、ROWNUM等）
创建支持快速刷新的物化视图日志（分区表专用）
对分区表建日志时，容易忽略 INCLUDING NEW VALUES 和 SEQUENCE 的组合使用——这是 UPDATE 场景下保证快速刷新正确的必要条件。
CREATE MATERIALIZED VIEW LOG ON sales_part WITH SEQUENCE, ROWID (prod_id, cust_id, time_id, amount) INCLUDING NEW VALUES;
说明：
-
WITH SEQUENCE是关键，它让日志记录变更顺序号，使快速刷新能正确处理同一行多次更新 -
INCLUDING NEW VALUES必须显式指定，否则 UPDATE 后的“新值”不会写入日志，导致刷新结果错乱 - 列列表（
prod_id, cust_id, ...）应覆盖物化视图 SELECT 中所有涉及的列；若漏掉某列，该列在刷新后可能为 NULL 或旧值
物化视图定义中避免触发完全刷新的陷阱
即使基表日志合规，物化视图定义稍有不慎，Oracle 就会静默降级为 COMPLETE 刷新（DBA_MVIEWS.REFRESH_METHOD = 'COMPLETE'），且不报错。
常见踩坑点：
- 使用了
TO_DATE('2023-01-01', 'YYYY-MM-DD')这类字面量表达式 → 视为“不可重写”，强制全刷 -
JOIN时用了外连接（LEFT JOIN）但未在日志中启用WITH PRIMARY KEY+INCLUDING NEW VALUES - 分区表上有局部索引但物化视图查询谓词未落在分区键上 → 优化器无法剪枝，可能绕过快速刷新路径
- 定义中写了
WHERE time_id >= TRUNC(SYSDATE) - 30→SYSDATE是非确定性函数，禁用快速刷新
验证快速刷新是否真正生效
别只看 DBMS_MVIEW.EXPLAIN_MVIEW 返回 “FAST REFRESHABLE” 就认为万事大吉。实际执行时仍可能 fallback。
实操建议：
- 手动触发一次
DBMS_MVIEW.REFRESH('<code>mv_sales_daily', 'F')，然后查V$MVREFRESH或DBA_MVIEW_REFRESH_TIMES，确认LAST_REFRESH_TYPE = 'FAST' - 检查
DBA_MVIEW_LOGS中LOG_TABLE行数是否随 DML 增长；如果没增长，说明 DML 未被日志捕获（日志建错或 DML 走了直通路径如INSERT /<em>+ APPEND </em>/） - 对分区表，特别留意是否发生“分区扩展”（如新增分区）：这会导致后续快速刷新失败，需手动
ALTER MATERIALIZED VIEW ... ENABLE QUERY REWRITE或重建日志
分区表上的快速刷新，真正复杂的地方不在语法，而在变更捕获链路是否全程可控：从 DML 发生 → 日志写入 → MV 刷新调度 → 查询重写生效，任一环脱节，就退化成全量刷。很多人卡在日志没带 SEQUENCE 却以为是物化视图定义问题，调半天才发现日志本身就不支持 UPDATE。
