最常见原因是至少一张基表的日志未建对：必须为每张基表显式创建含WITH ROWID及对应JOIN列的SEQUENCE日志，并在SELECT中显式引用各表ROWID别名，缺一即导致FAST静默退化为COMPLETE。
物化视图日志缺 ROWID 或未显式包含 JOIN 列
多表关联的物化视图快速刷新失败，最常见原因是至少一张基表的日志没建对。oracle 不会自动识别哪些列参与了连接，哪怕它们是主键或有索引。只要 sql 里写了 on orders.customer_id = customers.id，这两个列就必须分别出现在各自基表的日志中。
错误做法：CREATE MATERIALIZED VIEW LOG ON orders WITH PRIMARY KEY —— 这不保证 customer_id 被记录，尤其当它不是主键时。
正确写法必须显式列出：
CREATE MATERIALIZED VIEW LOG ON orders WITH ROWID, SEQUENCE(customer_id) INCLUDING NEW VALUES; CREATE MATERIALIZED VIEW LOG ON customers WITH ROWID, SEQUENCE(id) INCLUDING NEW VALUES;
如果用了复合 JOIN 条件（如 ON a.x = b.x AND a.y = b.y），两个列都得进 SEQUENCE()。
SELECT 列表漏了各基表的 ROWID 别名
快速刷新引擎靠每个基表的 ROWID 定位变更行。即使业务逻辑完全不需要，也必须显式写进 SELECT，否则整个刷新直接退化为 COMPLETE。
- 错误写法：
SELECT o.order_id, c.name FROM orders o JOIN customers c→ 缺o.ROWID和c.ROWID - 正确写法：
SELECT o.ROWID o_rowid, c.ROWID c_rowid, o.order_id, c.name FROM orders o JOIN customers c
别名必须唯一且可读（如 o_rowid、c_rowid），后续查 DBA_MVIEW_ANALYSIS 或排错全靠它。四张表 JOIN 就要写四个 xxx.ROWID xxx_rowid，一个都不能少。
REFRESH FAST 静默退化为 COMPLETE 却无提示
Oracle 19c 不会在你执行 REFRESH FAST 前报错，而是在运行时发现条件不满足就自动降级。你只会看到耗时飙升、LAST_REFRESH_DATE 更新了但结果没变，或者 USER_MVIEWS.STALENESS 显示 STALE 却刷不动。
排查关键动作：
- 运行
DBMS_MVIEW.EXPLAIN_MVIEW('mv_name')，重点看CAPABILITY_NAME = 'REFRESH_FAST'对应的POSSIBLE是否为'N'，以及MSGTXT提示（如"missing rowid"或"sequence column not logged"） - 查
USER_MVIEW_LOGS：确认每张基表都有对应日志，且ROWIDS = 'Y'（如果你用的是 ROWID 模式） - 哪怕只有一张表的日志缺
ROWID，整个物化视图就退化 —— 不会部分生效
外连接或 UNION 直接触发内核级拦截
LEFT JOIN、RIGHT JOIN、FULL OUTER JOIN 都不支持快速刷新，这不是配置问题，而是 Oracle 内部校验器在 CREATE MATERIALIZED VIEW 时就直接拒绝。语义上外连接无法被增量推导：左表某行删除后，你无法仅凭日志判断右表中哪些原本因该行而产生的 NULL 行该保留或该删。
同理，UNION ALL 也直接禁用快速刷新 —— 因其破坏“单源行映射”，同一结果行可能来自多个基表，增量变更无法准确定位。
这两类结构一旦出现，DBMS_MVIEW.EXPLAIN_MVIEW 输出中 REFRESH_FAST 的 POSSIBLE 必为 'N'，MSGTXT 会明确写 "outer join" 或 "set operator not supported"，没有绕过机制。
