Oracle多表关联物化视图能做FAST REFRESH，但需同时满足：显式创建含ROWID和SEQUENCE的日志、禁用子查询与外连接、JOIN仅限INNER、聚合必须含COUNT(*)及完整GROUP BY列、日志字段须对齐原始列且覆盖所有JOIN/WHERE列。
Oracle 多表关联物化视图能做 FAST REFRESH，但不是“建了日志就能刷”，而是必须让每张基表的日志结构、字段覆盖、JOIN 语义全部对齐——漏掉任何一个点，DBMS_MVIEW.EXPLAIN_MVIEW 就会返回 fastrefreshable = FALSE，且刷新时静默退化为 COMPLETE。
为什么多表 JOIN 的物化视图日志必须显式包含 ROWID 和 SEQUENCE
Oracle 快速刷新引擎靠 M_ROW$$ 定位变更行、靠 SEQUENCE$$ 保证操作顺序。如果只建 WITH PRIMARY KEY 日志，UPDATE/DELETE 就无法精确定位旧值或触发行级增量逻辑；而没 SEQUENCE，多个 DML 并发后顺序错乱，物化视图数据就会不一致。
- 必须显式写
WITH ROWID, SEQUENCE(col1, col2)，不能只依赖PRIMARY KEY -
SEQUENCE()里要包含所有被JOIN或WHERE引用的列（例如e.deptno = d.deptno，则emp和dept日志都得有deptno） - 如果 SELECT 中用了
UPPER(ename)，日志仍要包含原始列ename，不能只记表达式结果 - 基表 ALTER TABLE ADD COLUMN 后，日志不会自动同步，必须手动
ADD COLUMN，否则刷新报ORA-12052
LEFT JOIN / RIGHT JOIN 为什么直接导致 FAST 不可用
Oracle 19c 的快速刷新引擎不解析外连接语义，LEFT JOIN、RIGHT JOIN、甚至老式 (+) 写法，建 MV 时就可能报 ORA-12054，或刷新时报 ORA-32313。
- 安全替代方案是拆成
UNION ALL：第一部分INNER JOIN（可 FAST），第二部分用NOT EXISTS模拟左表无匹配行 -
NOT EXISTS子查询里，右表只能引用主键或唯一键列；一旦出现WHERE b.status = 'A'这类非键列过滤，整个物化视图就无法 FAST - 两部分的 SELECT 字段数、类型、NULL 性必须完全一致，否则
UNION ALL合并后结构不稳定，后续刷新可能失败
含 GROUP BY 的物化视图，日志和 SELECT 列必须严格对齐
聚合类物化视图对日志要求比普通 JOIN 更严：它必须能精确识别哪些行该增、删、改，因此依赖完整计数与分组锚点。
-
COUNT(*)是强制项，不能用COUNT(col)或SUM(x)替代，否则EXPLAIN_MVIEW直接标fastrefreshable = FALSE - SELECT 列表必须包含全部
GROUP BY列，不能省略（如GROUP BY cl.class_name，那 SELECT 里就必须有cl.class_name） - 所有参与聚合的基表，日志都必须带
INCLUDING NEW VALUES，且SEQUENCE()要覆盖所有被WHERE或JOIN引用的列（如mo_class_id,mo_id） - 如果某张基表日志缺了
INCLUDING NEW VALUES，即使其他条件全满足，刷新时也会跳过该表变更，导致数据滞后
如何用 EXPLAIN_MVIEW 快速定位日志问题
EXPLAIN_MVIEW 不是报错工具，而是能力清单。它告诉你“哪条能力缺失”，而不是“哪里写错了”。
- 先执行
EXEC DBMS_MVIEW.EXPLAIN_MVIEW('YOUR_MV_NAME'); - 再查
SELECT * FROM MV_CAPABILITIES_TABLE WHERE STATEMENT_ID = 'QSMQT_EXPLAIN_MVIEW'; - 重点关注
REFRESH_FROM_LOG_AFTER_INSERT和REFRESH_FROM_LOG_AFTER_ANY是否为DISABLED；若为UNKNOWN，说明日志结构或权限未排除 - 检查
BASE_TABLE行对应的CAPABILITY_NAME，比如REWRITE或FAST_REFRESH_AFTER_INSERT，看具体哪张表哪列不满足 - 别忽略
OBJECT_ID一致性：查DBA_OBJECTS和DBA_MVIEW_LOGS中的object_id与master_object_id是否相等，不等说明日志已断裂
最常被忽略的是日志表状态和基表 DDL 变更的耦合性——日志表被 TRUNCATE、基表主键被删、约束失效，这些都不会立刻报错，但会让 FAST 在某次刷新后突然失效，且错误日志里只显示“刷新完成”，实际数据已停滞。验证前务必先查 STATUS 和 COUNT(*)。
