Oracle Fast Refresh静默退化为COMPLETE是默认策略，不报错只切换；查DBA_MVIEWS.FAST_REFRESHABLE为'NO'或执行EXPLAIN_MVIEW可定位原因，如子查询、非确定性函数、基表TRUNCATE等均触发退化。
Fast Refresh 退化为 COMPLETE 不是异常，而是 Oracle 的默认降级策略 —— 它不报错，只静默切换。
为什么查不到错误却刷得慢？
Oracle 在每次 REFRESH FAST 执行前都会做一次可行性校验，只要发现定义或依赖不满足 FAST 条件，就直接走 COMPLETE 路径，且不抛 ORA 错误。你看到的“刷新变慢”，往往就是它已经退化了。
- 查
DBA_MVIEWS中的FAST_REFRESHABLE字段：值为'NO'或'DIRLOADDML'就说明不可 FAST；'FAST'才是真支持 - 执行
DBMS_MVIEW.EXPLAIN_MVIEW('MV_NAME')后查MVIEW_EXCEPTIONS表，里面每条MSGTXT都对应一个失败原因（比如 “not fast refreshable due to subquery”） - 刷新后立刻查
SELECT COUNT(*) FROM MLOG$_xxx WHERE SNAPTIME$$ > (SELECT LAST_REFRESH_DATE FROM DBA_MVIEWS WHERE MVIEW_NAME = 'MV_NAME')：结果为 0，说明根本没读日志，已退化
哪些写法会直接触发退化？
不是配置问题，是语法硬限制。Oracle 内核在解析物化视图定义时，一见到这些结构就关闭 FAST 路径：
- 任何子查询：
EXISTS、IN、NOT EXISTS、ANY、ALL—— 即使只是WHERE col IN (SELECT 1 FROM DUAL)也会让EXPLAIN_MVIEW返回fastrefreshable = FALSE - 聚合 + 分析函数嵌套：如
SUM(COUNT(*)) OVER(...)或ROW_NUMBER() OVER(...) = 1 - 非标准 JOIN：
FULL OUTER JOIN、RIGHT OUTER JOIN、含复杂 ON 条件的LEFT OUTER JOIN - 使用
SYSDATE、ROWNUM、DBMS_RANDOM.VALUE等非确定性函数
基表变更后为何突然退化？
基表结构稳定是 FAST 的前提。以下操作会破坏行级变更映射关系，导致下次刷新直接 COMPLETE：
- 基表被
TRUNCATE过：清空了MLOG$_xxx，但SNAPTIME$$没重置，FAST 试图读“不存在的变更”，触发ORA-12034 - 主键或唯一约束被删/改：日志里声明的
WITH PRIMARY KEY失效，刷新引擎 fallback 到 ROWID 模式 —— 若基表是索引组织表（IOT）或禁用了 ROWID，则 COMPLETE - 分区表新增分区但未验证日志覆盖范围：执行
ALTER TABLE ... ADD PARTITION后，EXPLAIN_MVIEW可能返回ORA-12052，表示无法识别新区的变更 - 物化视图日志字段缺失：比如基表加了新列，而日志没用
ADD补上，或建日志时漏了INCLUDING NEW VALUES，UPDATE/DELETE 就捕获不全
最容易被忽略的隐性退化点
有些问题不会立即暴露，但会在某次刷新后持续生效：
-
ON COMMIT物化视图若基表发生 DDL（如加列），后续第一次 COMMIT 会触发ORA-12008：因为承诺的 FAST 实际已不可行，但 Oracle 不提前预警 - 多个物化视图共用一张基表日志时，只要其中任意一个 MV 定义里漏了日志中声明的列（比如日志有
INCLUDING NEW VALUES，而某个 MV 查询只选旧值），所有依赖该日志的 FAST 刷新都会退化 - 远程物化视图（通过 DB Link）缺三要素任一：DB Link 未测试通、源库没建日志、MV 创建时没显式写
REFRESH FAST ON DEMAND—— 全部退化，且可能报ORA-12015
退化本身不可怕，可怕的是没人知道它发生了。真正要盯的不是“怎么让它 FAST”，而是“它现在是不是真在 FAST”。
