同步刷新（ON COMMIT）仅适用于极小数据量且强一致性要求的场景，因每次事务提交均触发增量更新，导致写入吞吐量下降30%–60%，并要求物化视图日志完备及基表有主键或唯一约束。
同步刷新（ON COMMIT）只适合极小数据量且强一致性要求的场景
当你在创建物化视图时指定 refresh fast on commit，oracle 会在每次基表事务提交后，**立即触发物化视图的增量更新**。这看似完美，但代价极高：每个 insert/update/delete 都会额外触发日志读取、变更应用、索引维护甚至可能的锁等待。实际压测中，写入吞吐量常下降 30%–60%，尤其当 mv 含 group by 或 join 时，单次提交延迟可能从毫秒级跳到数百毫秒。
它还隐含两个硬性前提：MATERIALIZED VIEW LOG 必须包含 ROWID 和所有 SELECT 列（含聚合键），且基表必须有主键或唯一约束；否则建 MV 会报错 ORA-12052: cannot fast refresh materialized view。
适用场景非常窄，例如：仅记录当日关键指标（如“当前库存水位”）的小表，且业务能容忍写操作变慢。
异步刷新（ON DEMAND）是生产环境的默认选择
绝大多数业务无法接受写链路被 MV 拖慢，所以用 REFRESH FAST ON DEMAND 是更现实的方案——刷新由 DBA 或调度器主动触发，与业务 DML 完全解耦。但这里有个关键细节：**“FAST”不等于“一定快”，它高度依赖物化视图日志的完备性**。
常见踩坑点包括：
- 忘记在源表上建日志，或建日志时漏了
INCLUDING NEW VALUES，导致 UPDATE 变更丢失 - 聚合 MV 中用了
TRUNC(sale_date)这类表达式，但日志没包含原始列sale_date，DBMS_MVIEW.REFRESH会静默降级为 COMPLETE - 用
DBMS_SCHEDULER调度时，未设置job_action中的刷新模式参数，比如写成DBMS_MVIEW.REFRESH('MV_NAME')（默认 FORCE），而不是明确指定'F'（FAST）
FORCE 刷新模式不是“兜底保险”，而是潜在性能雷区
REFRESH FORCE 的行为是：先尝试 FAST，失败则自动 fallback 到 COMPLETE。听起来省心，但在生产环境极易引发雪崩——某次日志损坏或统计信息过期，就可能让一个每小时跑一次的 MV 突然变成全量重建，占用大量 CPU、IO 和临时表空间，甚至阻塞其他作业。
更隐蔽的问题是：FORCE 不会报错提示“降级了”，你只能从 DBA_MVIEW_REFRESH_TIMES 查 LAST_REFRESH_DATE 和 LAST_REFRESH_TYPE 字段，或者监控 V$SESSION_LONGOPS 中异常长的 Refresh materialized view 操作。
建议始终显式指定 REFRESH FAST ON DEMAND，并在调度脚本里加校验逻辑，例如运行前先查 DBMS_MVIEW.EXPLAIN_MVIEW 确认是否支持 FAST。
增量刷新失败时，COMPLETE 并非万能解药
当 FAST 刷新失败（比如日志缺失、查询结构变更），直接切到 COMPLETE 看似合理，但要注意：COMPLETE 会执行 TRUNCATE + INSERT /*+ APPEND */，如果物化视图上有大索引，重建索引本身可能比查询还慢；若 MV 被用于查询重写（QUERY REWRITE），COMPLETE 过程中该 MV 会被标记为 STALE，优化器将跳过它，导致上游报表突然变慢。
真正稳妥的做法是：保留一份最近成功的 MV 副本（用 ON PREBUILT TABLE 创建），在 COMPLETE 刷新前先重命名旧表、刷新新表、再原子切换；同时确保 DBA_MVIEW_LOGS 中的 LOG_TABLE 行数不过大（长期不刷会导致日志膨胀，反而拖慢下一次 FAST）。
