物化视图快速刷新要求所有基表日志必须包含WITH ROWID及所有JOIN/WHERE列，且SELECT中需显式引用各表ROWID别名；否则降级为完全刷新。
物化视图日志必须包含所有关联列和ROWID
不加 rowid，快速刷新（fast refresh）会直接失败，报错 ora-12052: cannot fast refresh materialized view。oracle 要求每个基表的物化视图日志里，凡是在物化视图定义中参与 join 或 where 的列，都得显式出现在日志中；同时，rowid 是增量识别变更行的唯一依据，缺一不可。
实操建议：
- 建日志时必须带
WITH ROWID，例如：CREATE MATERIALIZED VIEW LOG ON orders WITH ROWID, SEQUENCE(order_id, customer_id) INCLUDING NEW VALUES;
- 所有 JOIN 列（如
orders.customer_id、customers.id）都要进对应日志的SEQUENCE子句 - 如果用了复合主键或非主键关联，别只依赖
PRIMARY KEY选项——它不保证日志含关联列，必须显式写SEQUENCE(...) - 多表关联时，每个基表日志独立配置，不能“一个日志覆盖多个表”
REFRESH FAST ON COMMIT 要求所有基表日志都启用 WITH ROWID
哪怕只有一个基表的日志漏了 ROWID，整个物化视图就退化为完全刷新（COMPLETE），且不会报错提示，只在执行时静默降级——你看到的刷新耗时突然飙升，大概率是这个原因。
常见错误现象：
- 明明写了
FAST，但DBA_MVIEW_ANALYSIS里显示FAST_REFRESHABLE为NO - 提交事务后物化视图没更新，查
USER_MVIEWS.REFRESH_MODE发现仍是DEMAND，实际因为日志不满足条件，系统自动忽略ON COMMIT - 用
EXPLAIN_MVIEW检查，输出里有fastrefreshable_after_insert = FALSE，并提示缺失ROWID或序列列
多基表 JOIN 下，ROWID 必须来自物化视图 SELECT 列表中的每个基表
Oracle 快速刷新引擎需要靠每个基表的 ROWID 定位变更行。如果你的物化视图 SQL 里 JOIN 了 orders 和 customers，但 SELECT 列表里只写了 orders.order_id、customers.name，没显式选任一表的 ROWID，刷新就会失败。
正确做法：
- 在物化视图定义的 SELECT 中，为每个基表加上别名后的
ROWID，例如：SELECT o.ROWID o_rowid, c.ROWID c_rowid, o.order_id, c.name FROM orders o JOIN customers c ON o.customer_id = c.id
- 别名命名要清晰，后续维护和排查依赖这些字段名
- 即使你不打算用这些
ROWID做业务逻辑，也必须保留——它们是刷新机制的“内部索引”，不是可选字段
复杂关联下，避免使用 OUTER JOIN 或 UNION ALL
Oracle 对快速刷新的支持边界很明确：INNER JOIN 可以，LEFT/RIGHT OUTER JOIN 默认不支持 FAST；含 UNION ALL 的物化视图，即使语法合法，EXPLAIN_MVIEW 也会标为不可快速刷新。
为什么？因为外连接引入空值匹配、多对一关系，增量变更无法无歧义地映射到物化视图行；而 UNION ALL 打乱了基表与物化视图行之间的确定性对应关系。
能做的妥协：
- 改用
INNER JOIN+ 补数据逻辑（比如用应用层兜底查缺失关联记录） - 拆成多个物化视图，各自单表或内连接，再用普通视图组合查询
- 接受定期 COMPLETE 刷新，把物化视图设为
REFRESH FORCE ON DEMAND，避开 FAST 限制
真正卡住人的，往往不是语法写错，而是日志建了但没带 ROWID，或者 SELECT 里漏了一个表的 ROWID 别名——这两处不报明显错误，只让刷新变慢、变不可控。
