Oracle 19c物化视图不支持含外连接的快速刷新，因外连接语义无法增量推导；替代方案是用UNION ALL拆解为INNER JOIN与NOT EXISTS两部分，并严格配置物化视图日志。
oracle 19c 的物化视图（materialized view）本身不支持直接基于含外连接（left join、right join）的查询定义进行快速刷新（fast refresh）。这是硬性限制，不是配置问题——哪怕你把刷新日志建得再全，只要查询里有外连接，on commit 或 on demand fast 刷新都会报错 ora-12054 或 ora-32313。
为什么外连接查询不能用于 FAST REFRESH 物化视图
快速刷新依赖物化视图日志（MATERIALIZED VIEW LOG）记录基表的变更行，并通过增量计算更新物化视图。但外连接的结果集语义是“保留左/右表所有行 + 匹配则填充，不匹配则补 NULL”，这种非对称扩展行为无法被增量式地、确定性地反向推导：比如左表某行被删除，你无法仅凭日志判断右表中哪些原本因该行而产生的 NULL 行该保留或该删；同理，右表新增一行时，也无法确认它是否应触发左表某行的重复展开（尤其在一对多场景下）。Oracle 内部校验器会在 CREATE MATERIALIZED VIEW 时直接拒绝这类定义。
-
FAST REFRESH仅支持内连接（INNER JOIN）、等值连接、无聚合、无子查询、无DISTINCT的简单连接场景 - 即使把外连接重写成
(+)语法（Oracle 旧式外连接），同样不被FAST支持 - 全外连接（
FULL OUTER JOIN）更不可用——连COMPLETE REFRESH都可能因 NULL 处理逻辑出错
替代方案：用 UNION ALL 拆解 LEFT JOIN 逻辑
若必须保留“左表全量 + 右表匹配数据”的语义且需可刷新，可行路径是手动等价改写：把 LEFT JOIN 拆成两部分 UNION ALL，并确保每部分都满足快速刷新条件。
- 第一部分：内连接结果（
INNER JOIN）→ 可建日志、可FAST REFRESH - 第二部分：左表中无匹配的行（
NOT EXISTS子查询）→ 必须用主键或唯一键关联，且子查询中不能引用右表非键列，否则仍会失败 - 两部分字段顺序、类型、NULL 性必须严格一致，否则
UNION ALL合并后物化视图结构不稳定
示例（假设 dept 左表，emp 右表）：
CREATE MATERIALIZED VIEW mv_dept_emp_fast REFRESH FAST ON DEMAND AS SELECT d.deptno, d.dname, e.empno, e.ename FROM dept d, emp e WHERE d.deptno = e.deptno UNION ALL SELECT d.deptno, d.dname, TO_NUMBER(NULL), CAST(NULL AS VARCHAR2(10)) FROM dept d WHERE NOT EXISTS ( SELECT 1 FROM emp e WHERE e.deptno = d.deptno );
注意：TO_NUMBER(NULL) 和 CAST(NULL AS VARCHAR2(10)) 是为强制类型对齐，避免隐式转换导致刷新失败。
刷新日志配置要点（仅对内连接部分有效）
即使拆解后，也必须为所有参与表正确创建物化视图日志，且包含外连接中实际用到的列（尤其是连接键和 SELECT 列）：
- 对
dept表：需WITH PRIMARY KEY或WITH ROWID，并显式包含deptno,dname - 对
emp表：同样需WITH PRIMARY KEY，并包含empno,ename,deptno - 不能只建
WITH SEQUENCE—— 它不记录具体列值变更，FAST REFRESH会退化为COMPLETE - 日志表名默认为
MLOG$_，可通过DBA_MVIEW_LOGS确认是否启用
真正麻烦的地方不在语法，而在语义一致性：外连接天然引入的 NULL 扩展，在物化视图生命周期中极易因基表约束变更、NULL 值误更新、或刷新时机交错而产生歧义结果。与其强行绕过限制，不如先确认业务是否真的需要实时性——很多时候，COMPLETE REFRESH ON DEMAND 配合低峰期执行，反而比勉强维护一个“伪快速”物化视图更可靠。
