Oracle物化视图Fast Refresh为何退化为全量刷新

Oracle Fast Refresh静默退化为COMPLETE是默认策略，不报错只切换；查DBA_MVIEWS.FAST_REFRESHABLE为'NO'或执行EXPLAIN_MVIEW可定位原因，如子查询、非确定性函数、基表TRUNCATE等均触发退化。

Fast Refresh 退化为 COMPLETE 不是异常，而是 Oracle 的默认降级策略 —— 它不报错，只静默切换。

为什么查不到错误却刷得慢？

Oracle 在每次 REFRESH FAST 执行前都会做一次可行性校验，只要发现定义或依赖不满足 FAST 条件，就直接走 COMPLETE 路径，且不抛 ORA 错误。你看到的“刷新变慢”，往往就是它已经退化了。

1. 查 DBA_MVIEWS 中的 FAST_REFRESHABLE 字段：值为 'NO' 或 'DIRLOADDML' 就说明不可 FAST；'FAST' 才是真支持
2. 执行 DBMS_MVIEW.EXPLAIN_MVIEW('MV_NAME') 后查 MVIEW_EXCEPTIONS 表，里面每条 MSGTXT 都对应一个失败原因（比如 “not fast refreshable due to subquery”）
3. 刷新后立刻查 SELECT COUNT(*) FROM MLOG$_xxx WHERE SNAPTIME$$ > (SELECT LAST_REFRESH_DATE FROM DBA_MVIEWS WHERE MVIEW_NAME = 'MV_NAME')：结果为 0，说明根本没读日志，已退化

哪些写法会直接触发退化？

不是配置问题，是语法硬限制。Oracle 内核在解析物化视图定义时，一见到这些结构就关闭 FAST 路径：

1. 任何子查询：EXISTS、IN、NOT EXISTS、ANY、ALL —— 即使只是 WHERE col IN (SELECT 1 FROM DUAL) 也会让 EXPLAIN_MVIEW 返回 fastrefreshable = FALSE
2. 聚合 + 分析函数嵌套：如 SUM(COUNT(*)) OVER(...) 或 ROW_NUMBER() OVER(...) = 1
3. 非标准 JOIN：FULL OUTER JOIN、RIGHT OUTER JOIN、含复杂 ON 条件的 LEFT OUTER JOIN
4. 使用 SYSDATE、ROWNUM、DBMS_RANDOM.VALUE 等非确定性函数

基表变更后为何突然退化？

基表结构稳定是 FAST 的前提。以下操作会破坏行级变更映射关系，导致下次刷新直接 COMPLETE：

1. 基表被 TRUNCATE 过：清空了 MLOG$_xxx，但 SNAPTIME$$ 没重置，FAST 试图读“不存在的变更”，触发 ORA-12034
2. 主键或唯一约束被删/改：日志里声明的 WITH PRIMARY KEY 失效，刷新引擎 fallback 到 ROWID 模式 —— 若基表是索引组织表（IOT）或禁用了 ROWID，则 COMPLETE
3. 分区表新增分区但未验证日志覆盖范围：执行 ALTER TABLE ... ADD PARTITION 后，EXPLAIN_MVIEW 可能返回 ORA-12052，表示无法识别新区的变更
4. 物化视图日志字段缺失：比如基表加了新列，而日志没用 ADD 补上，或建日志时漏了 INCLUDING NEW VALUES，UPDATE/DELETE 就捕获不全

最容易被忽略的隐性退化点

有些问题不会立即暴露，但会在某次刷新后持续生效：

1. ON COMMIT 物化视图若基表发生 DDL（如加列），后续第一次 COMMIT 会触发 ORA-12008：因为承诺的 FAST 实际已不可行，但 Oracle 不提前预警
2. 多个物化视图共用一张基表日志时，只要其中任意一个 MV 定义里漏了日志中声明的列（比如日志有 INCLUDING NEW VALUES，而某个 MV 查询只选旧值），所有依赖该日志的 FAST 刷新都会退化
3. 远程物化视图（通过 DB Link）缺三要素任一：DB Link 未测试通、源库没建日志、MV 创建时没显式写 REFRESH FAST ON DEMAND —— 全部退化，且可能报 ORA-12015

退化本身不可怕，可怕的是没人知道它发生了。真正要盯的不是“怎么让它 FAST”，而是“它现在是不是真在 FAST”。