能用fast且业务允许秒级至分钟级延迟就优先用fast，否则用complete；fast需严格满足日志、sql语法、约束等条件，complete稳定可控但耗时，force仅自动降级不报错。
COMPLETE 和 FAST 刷新不是性能“好与坏”的二选一，而是“能不能用”和“值不值得用”的权衡。直接结论：能用 FAST 且业务允许延迟（秒级到分钟级），就优先用 FAST；否则老老实实用 COMPLETE，别硬上 FAST 搞出刷新失败或数据不一致。
FAST 刷新的前提条件比你想象中更严格
FAST 不是加个日志就能开的开关，它依赖一套完整且精确匹配的基础设施：
- 基表必须有物化视图日志（
MATERIALIZED VIEW LOG），且日志里包含所有 SELECT 中涉及的列（尤其是ROWID、SEQUENCE、INCLUDING NEW VALUES） - 物化视图定义不能含分析函数（如
ROW_NUMBER()、RANK()）、SYSDATE、子查询中的聚合嵌套过深、远程表（@dblink）等 - 如果物化视图基于多张表连接，所有基表都得建日志，且连接字段需有主外键约束或唯一性保证
-
DBMS_MVIEW.EXPLAIN_MVIEW是唯一靠谱的验证手段——运行它，看输出里capable\_of\_fast\_refresh是否为YES，别凭经验猜
ORA-12004: REFRESH FAST cannot be used for this materialized view，往往就是上述某条没满足，而不是权限或空间问题。
COMPLETE 刷新看似慢，但稳定性和可控性更高
COMPLETE 的本质是重建：先 TRUNCATE（快，不记重做），再全量 INSERT /*+ APPEND */（可并行，走直接路径）。它的优势不在速度，而在确定性：
- 不受基表 DML 频率影响——哪怕源表每秒上千次变更，
COMPLETE刷新一次仍是可预期的耗时 - 无需维护物化视图日志，省去日志表膨胀、归档压力、
LOGGING模式切换等额外运维负担 - 支持任意复杂 SQL（含分析函数、UDF、跨库查询），没有语法限制
- 刷新期间老数据仍可读（事务隔离保证），只在最后
COMMIT时原子切换，对应用透明
FORCE 刷新不是“智能选择”，而是“降级兜底”
FORCE 行为完全取决于 Oracle 内部检查结果，它不会帮你绕过限制，只会默默 fallback 到 COMPLETE：
- 当你设为
REFRESH FORCE ON DEMAND，每次调用DBMS_MVIEW.REFRESH时都会重新校验是否支持FAST - 如果某次因日志损坏、统计信息过期、或隐式类型转换导致校验失败，就会退成
COMPLETE，但不会报错提醒你——可能连续几天都在跑全量 - 监控关键指标只能看
USER_MVIEWS.LAST_REFRESH_DATE和LAST_REFRESH_TYPE字段，后者会明确记录是C还是F
FAST 条件时临时启用。
真正影响决策的是刷新频率和数据新鲜度要求
FAST 的价值只在高频刷新场景下才体现出来：
- 每小时刷一次：用
FAST可能几秒完成，COMPLETE要几分钟 → 推荐FAST - 每天刷一次：即使
COMPLETE耗时 5 分钟，也远低于日间窗口，且省去日志管理 → 推荐COMPLETE - 需要准实时（
ON COMMIT）：只有FAST支持，但代价是 DML 延迟上升，且必须满足全部前提 → 必须严格验证
FAST 可能得不偿失。
