先看一个关键结论：在配置物化视图日志时，必须显式包含 WHERE 条件中涉及的所有列，且不能使用别名，也不能遗漏任何一个过滤字段。否则，fast 刷新会直接降级为 complete，甚至刷新失败。这可不是小事，数据一致性一旦出现问题，后续排查会非常棘手。
物化视图日志中漏掉 WHERE 字段会导致增量刷新失效
举个例子，假设物化视图里添加了 WHERE pay_status = 1 这个过滤条件。如果日志中没有包含 pay_status 这个列，Oracle 就无法判断某条记录是否仍然在过滤范围内。这样一来，UPDATE 或 DELETE 操作就可能被跳过，最终造成数据不一致，这种后果谁都不希望遇到。
实际工作中，你可能会遇到这些问题：
ORA-12057: materialized view is invalid and must be compiled—— 日志列缺失时的典型错误- 执行
DBMS_MVIEW.REFRESH时，明明指定了FAST，结果却走了COMPLETE刷新 - 查看日志表
MLOG$_T_ORDER，发现缺少对应字段，用SELECT * FROM user_mview_logs可以确认
具体操作时，建议你先做一步：反推物化视图 SQL 中所有参与 WHERE、GROUP BY、SELECT 聚合的原始列，注意是原始列名，不是别名。比如：
- 如果用了
TRUNC(create_time)，日志里只需写create_time - 如果用了
UPPER(name)，日志里必须包含name，不能只写UPPER(name)
WITH SEQUENCE 和 INCLUDING NEW VALUES 是单表聚合 MV 的硬性要求
只要物化视图里包含了 SUM、COUNT、GROUP BY 这类聚合操作，Oracle 就强制要求日志带上 SEQUENCE 和 INCLUDING NEW VALUES。这两个参数缺一不可，否则即使列都齐了，FAST 刷新也会拒绝执行。
正确的写法如下：
CREATE MATERIALIZED VIEW LOG ON t_order WITH PRIMARY KEY, SEQUENCE(create_time, pay_amount, pay_status) INCLUDING NEW VALUES;
这里有几点需要注意：
SEQUENCE不是可选项——它保证了 DML 操作的顺序，聚合类 MV 必须依赖它INCLUDING NEW VALUES是必须的，EXCLUDING是默认值，但会导致聚合 MV 无法FAST刷新- 不能同时指定
PRIMARY KEY和括号里再列主键列，比如WITH PRIMARY KEY (id)会直接报错
主键列会自动记录，别重复声明
如果表有主键，使用 PRIMARY KEY 子句后，Oracle 会自动将主键列写入日志。如果你再在 SEQUENCE(...) 里重复写它们，语法上虽然不报错，但逻辑冗余，还可能干扰解析，多一事不如少一事。
以 t_order 表为例，主键是 order_id，下面两种写法效果一样，但后者更简洁：
- ✅ 推荐写法：
WITH PRIMARY KEY, SEQUENCE(create_time, pay_amount, pay_status) - ❌ 冗余写法：
WITH PRIMARY KEY, SEQUENCE(order_id, create_time, pay_amount, pay_status)
这里要特别提醒：ROWID 不能替代 PRIMARY KEY。聚合类 MV 明确要求使用主键方式，否则直接拒绝创建 FAST 刷新支持。
大小写和对象名要严格匹配基表定义
Oracle 默认对未加引号的标识符会转大写。如果你建表时用了小写字段名并加了双引号，比如 "create_time"，那么日志语句里也必须用双引号，否则系统找不到这个列。
最稳妥的做法是：
- 先查基表真实列名：
SELECT column_name FROM user_tab_columns WHERE table_name = 'T_ORDER' - 直接复制粘贴列名，避免手敲时大小写出错
- 不要在日志里用
AS别名——日志只认物理列名，TRUNC(create_time) AS stat_date对日志毫无意义
一个容易被忽略的细节：物化视图日志本身不校验字段是否存在，只有真正执行 REFRESH FAST 时才会暴露问题。所以，配置完一定要跑一次手动刷新来验证，不能只看 CREATE 成功就认为万事大吉了。
