FAST刷新比COMPLETE快得多，因其仅增量应用物化视图日志中的变更记录，不扫描基表、不重建全量数据；而COMPLETE需全表扫描+重执行查询，耗尽IO、CPU与临时表空间。
FAST刷新为什么比COMPLETE快得多
因为FAST是增量更新：只读取物化视图日志（MLOG$_表）中自上次刷新以来的变更记录，再应用到物化视图上。它不碰原始基表数据，也不重建整个结果集。COMPLETE则是删光重来——对小表可能用TRUNCATE，大表就是全表扫描+重新执行物化视图定义SQL，IO、CPU、临时表空间全拉满。
典型场景下，一次FAST刷新耗时在毫秒级（比如几十ms），而同等数据量的COMPLETE可能要几分钟。压测数据显示：当基表单日新增10万行，FAST刷新平均耗时42ms；COMPLETE则稳定在3.2min左右，且随数据增长线性恶化。
FAST刷新不是“开箱即用”，失败就静默退化为COMPLETE
REFRESH FORCE看起来省心，但它是性能陷阱：内部按FAST → COMPLETE顺序尝试，失败不报错、不写告警日志，只悄悄切到COMPLETE。你只能事后查DBA_MVIEW_REFRESH_TIMES.LAST_REFRESH_TYPE字段，或者翻V$SESSION_LONGOPS里那些耗时异常长的Refresh materialized view记录。
常见导致FAST降级的原因包括：
- 物化视图日志缺失
INCLUDING NEW VALUES，UPDATE后新值进不了日志，FAST逻辑无法还原状态 - 建日志时没加
WITH SEQUENCE，同一行被多次UPDATE时中间变更丢失 - MV定义里用了
TRUNC(sale_date)，但日志只记了表达式结果，没包含原始列sale_date - 基表主键变更或统计信息过期，导致
DBMS_MVIEW.EXPLAIN_MVIEW返回capable_name = 'UNUSABLE'
COMPLETE刷新的资源开销集中在临时表空间和锁竞争
COMPLETE刷新会触发完整查询重执行，这意味着：
- 大量排序、哈希聚合操作，吃掉
TEMP表空间；某次调度中因TEMP不足直接报ORA-01652 - 刷新期间对物化视图加
SS（sub-share）锁，阻塞部分SELECT；若MV上有索引，重建索引还会短暂升级为X锁 - 如果MV定义含多表JOIN或GROUP BY，优化器可能选择嵌套循环而非哈希连接，进一步放大CPU消耗
尤其要注意：即使你写了REFRESH FAST ON DEMAND，只要调度脚本里漏了模式参数（如只调DBMS_MVIEW.REFRESH('MV_SALES')），Oracle默认走FORCE，等于埋了个定时COMPLETE炸弹。
验证FAST是否真在跑，不能只看调度是否成功
调度任务返回“success”不代表FAST生效。必须组合三处检查：
- 刷新前：查
DBA_MVIEW_LOGS确认日志存在、LOG_TABLE非空、SEQUENCE#和NEW_VALUES列为YES - 刷新中：运行
DBMS_MVIEW.EXPLAIN_MVIEW('MV_SALES')，重点看MSGTXT字段是否含'fast refreshable'且无'unusable'字样 - 刷新后：立刻查
DBA_MVIEW_REFRESH_TIMES，确认LAST_REFRESH_TYPE = 'FAST'，且LAST_REFRESH_DATE与调度时间偏差
忽略任一环，都可能让本该毫秒级的增量刷新，在某天凌晨变成吃光CPU、拖垮备份窗口的全量重建。最隐蔽的问题往往不在创建时，而在日志维护或统计信息老化之后。
