Oracle物化视图对UNION ALL的快速刷新是内核级硬限制，语法解析阶段即拦截，REFRESH_FAST_POSSIBLE恒为'N'；因其破坏单源行映射，导致增量变更无法准确定位，无绕过机制，必须改用COMPLETE刷新或拆分为多个独立物化视图。
oracle 物化视图对 union all 的快速刷新支持是硬性禁止的，不是配置问题，也不是版本差异导致的疏漏——它在语法解析阶段就被内核直接拦截，refresh_fast_possible 永远返回 'n'。
UNION ALL 为什么直接触发 REFRESH_FAST_POSSIBLE = 'N'
Oracle 快速刷新依赖物化视图日志（MLOG$_）中每行变更的精确记录：包括 ROWID、操作类型（INSERT/UPDATE/DELETE）、以及该行唯一归属的基表。而 UNION ALL 天然破坏“单源行映射”——同一结果行可能来自多个分支查询，且没有确定性归属。删除某行时，系统无法判断它原始来自哪个分支、是否已被另一分支覆盖。这种不确定性让增量计算不可靠，所以 Oracle 不会等到日志或约束校验阶段，而是在 SQL 解析时就标记为不可快速刷新。
验证方式很直接：DBMS_MVIEW.EXPLAIN_MVIEW('mv_name') 查询 MVIEW_EXCEPTIONS 表，CAPABILITY_NAME = 'REFRESH_FAST' 对应行的 POSSIBLE 列必为 'N'，MSGTXT 通常含 "UNION ALL" 或 "set operator not supported"，RECOMMENDATION 字段明确写 UNION ALL ——这不是建议，是判决依据。
即使满足所有其他条件，UNION ALL 仍不可绕过
常见误区是以为只要建好日志、加好 SEQUENCE、保证每个分支都可单独快速刷新，就能让整个 UNION ALL 物化视图支持快速刷新。事实并非如此：
- 所有基表都建了
WITH ROWID, SEQUENCE, INCLUDING NEW VALUES的物化视图日志 - 每个
SELECT分支本身都满足快速刷新限制（无聚合、无分析函数、字段类型兼容） - 显式包含各分支的
ROWID和常量标识列（如1 AS marker） - 兼容性设置为
9.2.0或更高（但实际 11g/12c/19c 均不例外）
以上全部满足，REFRESH FAST 依然报错或静默退化为 COMPLETE。这不是 bug，是 Oracle 内核级设计决定。
哪些“看起来像 UNION”的写法也踩坑
很多人尝试用变通方式绕开限制，但多数仍会失败：
-
SELECT * FROM (SELECT ... FROM t1 UNION ALL SELECT ... FROM t2)：子查询套一层，UNION ALL不在顶层 → 不支持 -
WHERE中含OR模拟分支逻辑（如t1.status = 'A' OR t2.status = 'B'）→ 触发MSGNO = 2031，快速刷新被拒 - 用
FULL OUTER JOIN + CASE替代UNION ALL：必须满足两表有唯一连接键、ON条件不含函数或非等值、SELECT显式包含双方ROWID；稍有偏差（比如漏掉一个ROWID）就报MSGNO = 2012 - 基于视图创建物化视图，而该视图定义含
UNION ALL：即使加ON PREBUILT TABLE，也只是跳过语法校验，后续FAST REFRESH仍会因无法追踪变更路径而失败或数据错乱
真正可行的替代路径只有两个
别在“怎么让 UNION ALL 快刷”上耗时间，现实选项很窄：
-
改用
REFRESH COMPLETE或REFRESH FORCE：这是最常用、最稳妥的做法。尤其当基表 DML 频率不高、或物化视图数据量可控时，COMPLETE的开销远小于调试伪替代方案的成本 -
拆成多个独立物化视图，应用层合并：例如为每个
UNION分支单独建一个支持快速刷新的物化视图，再用视图或应用逻辑做UNION ALL合并。虽然增加对象管理成本，但每个部分都可稳定快速刷新，语义清晰、可监控、易排障
试图用 JOIN 模拟 UNION ALL 的写法极难保证语义等价，且一旦基表数据分布变化（比如某分支为空），结果可能悄然出错——这种隐性风险比定期全刷更危险。
