Oracle 19c中含子查询的物化视图无法启用FAST刷新，因内核级硬拦截：子查询破坏行级变更与结果的确定性映射，刷新引擎仅语法扫描即禁用FAST路径，自动降级为COMPLETE刷新。
Oracle 19c 中，任何含子查询的物化视图都无法启用 FAST 刷新——这不是配置能绕过的限制，而是内核级硬拦截。
为什么子查询直接禁用 FAST REFRESH
Oracle 快速刷新依赖物化视图日志（MLOG$_）中精确记录的行级变更，并通过确定性映射重算结果。子查询（如 EXISTS、IN、NOT EXISTS、ANY、ALL 或非关联子查询）破坏了这种映射能力：
- 关联子查询无法将外层行变更与内层子查询结果变化做可逆绑定
- 非关联子查询引入全局聚合状态（如
(SELECT MAX(val) FROM stats)），日志无法捕获其“变化边界” - Oracle 刷新引擎不解析逻辑，仅做语法扫描；一检测到子查询关键字，立即关闭 FAST 路径
执行 DBMS_MVIEW.EXPLAIN_MVIEW('mv_name') 后查 MVIEW_EXCEPTIONS，必然看到 fastrefreshable = 'FALSE' 和 RECOMMENDATION = 'SUBQUERY'。
建 MV 时不会报错，但刷新会静默退化为 COMPLETE
你仍能成功执行 CREATE MATERIALIZED VIEW ... AS SELECT * FROM t1 WHERE x IN (SELECT y FROM t2)，但后续调用 DBMS_MVIEW.REFRESH('mv_name', 'F') 时：
- 不会报错，也不会走增量逻辑
- Oracle 自动降级为
COMPLETE刷新（全量重跑整个 SELECT） - 性能取决于远程表大小、网络延迟和查询复杂度，且无事务一致性保障
若误以为“加了 REFRESH FAST ON DEMAND 就能增量”，实际每次都是全刷，还可能因超时或锁表引发故障。
可行的替代方案：用 JOIN + 显式日志重构
部分子查询语义可等价转写为连接结构，前提是满足 FAST 所有前置条件（主键、日志字段对齐、无聚合等）：
-
EXISTS (SELECT 1 FROM t2 WHERE t2.id = t1.ref)→ 改为INNER JOIN t2 ON t1.ref = t2.id，并确保t1和t2都建了含ROWID、SEQUENCE及关联列的日志 -
NOT EXISTS→ 不能直接用LEFT JOIN ... IS NULL（该写法本身也不支持 FAST），需拆成UNION ALL：匹配部分（INNER JOIN） + 不匹配部分（SELECT ... FROM t1 WHERE NOT EXISTS (SELECT 1 FROM t2 WHERE ...)，但仅限单表主键关联场景） -
IN (SELECT deptno FROM dept WHERE loc = 'DALLAS')→ 若dept主键是deptno，可建日志WITH PRIMARY KEY, SEQUENCE(deptno, loc) INCLUDING NEW VALUES，再用JOIN替代
关键点：CREATE MATERIALIZED VIEW LOG ON dept WITH PRIMARY KEY, SEQUENCE(deptno, loc) INCLUDING NEW VALUES —— SEQUENCE 必须覆盖子查询中所有被引用字段，否则仍退化。
如果必须保留子查询逻辑，就别碰 FAST
强行尝试“修复”子查询以启用 FAST 是徒劳的。更务实的做法是：
- 明确使用
REFRESH COMPLETE ON DEMAND，并用DBMS_SCHEDULER定期调用DBMS_MVIEW.REFRESH('mv_name', 'C') - 若跨库（含
@dblink），COMPLETE是唯一合法选项，且需验证 DBLINK 权限是否精准（GRANT SELECT ON schema.table TO local_user，非SELECT ANY TABLE） - 大结果集刷新时设
atomic_refresh => FALSE避免长事务锁表，但接受短暂数据不一致
真正容易被忽略的是：子查询禁用 FAST 的判断发生在语法解析阶段，不是运行时。哪怕你把子查询封装进一个视图再基于该视图建 MV，只要最终展开后含子查询，EXPLAIN_MVIEW 依然返回 FALSE。
