Oracle 19c 不支持任何含子查询的物化视图进行FAST刷新，因其破坏行级变更的确定性映射；子查询（如EXISTS、IN、NOT EXISTS等）会直接导致DBMS_MVIEW.EXPLAIN_MVIEW返回fastrefreshable=FALSE，刷新时静默退化为COMPLETE。
oracle 19c 不支持任何含子查询的物化视图进行 fast 刷新——这不是配置问题，而是内核级硬限制。只要 select 中出现 exists、not exists、in、any、all 或非关联子查询，dbms_mview.explain_mview 就会返回 fastrefreshable = false，且建 mv 时不会报错，只在刷新时静默退化为 complete。
为什么子查询直接禁用 FAST REFRESH
快速刷新依赖物化视图日志（MLOG$_）中精确记录的行级变更，并通过确定性增量算法重算结果。子查询破坏了这种确定性：
- 关联子查询（如
WHERE x IN (SELECT y FROM t2 WHERE t2.id = t1.ref)）无法将外层行变更与内层子查询结果变化做可逆映射 - 非关联子查询（如
WHERE col > (SELECT MAX(val) FROM stats)）引入全局聚合状态，日志无法捕获其“变化边界” - Oracle 的刷新引擎不解析子查询逻辑，仅做语法扫描；一旦检测到子查询关键字，立即关闭 FAST 路径
替代方案：用 JOIN + UNION ALL 拆解常见子查询模式
部分子查询语义可等价转写为连接结构，前提是满足 FAST 刷新所有前置条件（主键、日志、列覆盖等）：
-
NOT EXISTS→ 改写为LEFT JOIN ... WHERE right_table.pk IS NULL，但注意：LEFT JOIN 本身也不支持 FAST，必须进一步拆成UNION ALL：内连接部分 + 左表无匹配部分（用NOT EXISTS但仅限单表主键关联） -
EXISTS→ 改写为INNER JOIN，这是最安全的路径；确保两个基表都有完整日志（含 JOIN 列、INCLUDING NEW VALUES、WITH PRIMARY KEY） -
IN (subquery)→ 若子查询只查单列主键，可转为INNER JOIN；若含聚合或多列，必须用MATERIALIZED VIEW LOG ON目标表 + 显式SEQUENCE()列覆盖子查询中所有被引用字段
示例（原 SELECT * FROM emp WHERE deptno IN (SELECT deptno FROM dept WHERE loc = 'DALLAS')）：
CREATE MATERIALIZED VIEW LOG ON dept WITH PRIMARY KEY, SEQUENCE(deptno, loc) INCLUDING NEW VALUES; CREATE MATERIALIZED VIEW LOG ON emp WITH PRIMARY KEY, SEQUENCE(empno, deptno) INCLUDING NEW VALUES; <p>CREATE MATERIALIZED VIEW mv_emp_dallas REFRESH FAST ON DEMAND AS SELECT e.* FROM emp e, dept d WHERE e.deptno = d.deptno AND d.loc = 'DALLAS';
哪些子查询连改写都不行，必须放弃 FAST
以下情况没有合规替代路径，FAST 刷新不可达：
- 子查询中使用
SYSDATE、USER、ROWNUM等非确定性函数 - 子查询跨数据库链接（
@dblink），即使目标库也启用了日志 - 子查询含聚合（
GROUP BY、SUM等）且未配COUNT(*)和主键 - 子查询嵌套超过一层（如
WHERE x IN (SELECT y FROM t2 WHERE z IN (SELECT w FROM t3))） - 子查询出现在
SELECT列表中（标量子查询），例如SELECT name, (SELECT COUNT(*) FROM orders o WHERE o.cust_id = c.id) cnt FROM customers c
真正容易被忽略的是：**子查询是否被 Oracle 解析器识别，和它看起来多简单无关**。哪怕只是 WHERE id IN (SELECT 1 FROM DUAL)，也会触发 fastrefreshable = FALSE。验证唯一可靠方式是执行 DBMS_MVIEW.EXPLAIN_MVIEW 并检查输出中的 MSGTXT 字段，而不是依赖建表成功与否。
