物化视图FAST REFRESH需显式创建字段对齐的日志（含SEQUENCE和ROWID），基表须有主键/唯一约束，MV定义须明确REFRESH FAST ON COMMIT或调用DBMS_MVIEW.REFRESH('F')，JOIN仅支持INNER及部分LEFT OUTER，否则退化为COMPLETE刷新。
物化视图日志必须显式创建，且字段要对齐基表
oracle 不会自动为基表建日志，fast refresh 前这步漏掉，后续所有配置都白搭。日志不是“开个开关”，它得存增量变更记录，所以字段必须和物化视图 select 列严格对应——尤其是涉及表达式、函数或别名时，日志里得有对应列。
-
CREATE MATERIALIZED VIEW LOG ON emp WITH SEQUENCE, ROWID (empno, ename, deptno) INCLUDING NEW VALUES;——SEQUENCE和ROWID是 FAST REFRESH 必需的，缺一不可 - 如果物化视图里写了
UPPER(ename)，日志里就得包含ename原始列，不能只记计算结果 - 基表加了新列？日志不会自动同步，得手动
ADD，否则刷新报ORA-12052: cannot fast refresh materialized view
物化视图定义里必须带 REFRESH FAST ON COMMIT 或显式指定刷新方式
只写 REFRESH FAST 不够，Oracle 需要知道触发时机。常见误区是以为建完就能自动增量刷，其实默认是 ON DEMAND，不调 DBMS_MVIEW.REFRESH 就不动。
-
CREATE MATERIALIZED VIEW mv_emp_dept REFRESH FAST ON COMMIT AS SELECT e.empno, e.ename, d.dname FROM emp e JOIN dept d ON e.deptno = d.deptno;—— 这样才能在每次COMMIT后自动增量更新 - 如果用
ON DEMAND，必须配DBMS_MVIEW.REFRESH('mv_emp_dept', 'F')，'F'表示 FAST，错写成'C'（COMPLETE）就全量刷了 - JOIN 类型有限制：只支持
INNER JOIN和某些LEFT OUTER JOIN，FULL OUTER或RIGHT OUTER直接禁用 FAST REFRESH
刷新失败时先查 DBA_MVIEWS 和 DBA_MVIEW_LOGS 状态
报 ORA-12052 或 ORA-12008 时，不是代码写错了，而是依赖链断了。Oracle 检查很细：基表日志是否存在、是否含必要字段、物化视图查询是否满足限制条件（比如没聚合、没 DISTINCT、没子查询）。
- 查日志状态：
SELECT LOG_TABLE, MASTER, ROWIDS, SEQUENCE FROM DBA_MVIEW_LOGS WHERE MASTER = 'EMP';—— 确认ROWIDS = 'YES'且SEQUENCE = 'YES' - 查物化视图能力：
SELECT CAN_USE_LOG, LAST_REFRESH_DATE, STALENESS FROM DBA_MVIEWS WHERE MVIEW_NAME = 'MV_EMP_DEPT';——CAN_USE_LOG = 'NO'就说明日志不匹配 - 执行
EXEC DBMS_MVIEW.EXPLAIN_MVIEW('mv_emp_dept');，再查MVIEW_EXCEPTIONS表，能定位具体哪条规则不满足
主键/唯一约束影响 FAST REFRESH 的可行性
Oracle 靠 ROWID + 日志里的 SEQUENCE 定位变更行，但如果基表没主键或唯一约束，JOIN 或 GROUP BY 场景下无法保证行级可追溯，就会退化成 COMPLETE 刷新。
- 即使物化视图本身不包含主键列，基表也得有
PRIMARY KEY或UNIQUE NOT NULL约束，否则FAST REFRESH被拒 - 多表 JOIN 时，所有关联字段必须来自约束列；例如
emp.deptno关联dept.deptno，那dept.deptno得是主键 - 用
DBMS_MVIEW.VALIDATE_MVIEW可提前验证约束兼容性，比等刷新失败再排查快得多
真正卡住人的往往不是语法，而是日志字段和基表约束的隐式耦合——改一个字段类型、删一条约束、少建一个日志列，FAST REFRESH 就悄无声息地退化成全量刷，还未必报错。
