物化视图的增量刷新不依赖业务时间字段（如where create_time >= sysdate-1），而是严格依赖物化视图日志（mlog$_xxx）捕获的dml变更记录；fast刷新仅识别“哪些行被修改”，不按业务时间过滤，且sysdate等动态函数会导致fast不可用，真正的时间段增量需人工维护水位并显式包含时间字段于日志与查询中。
不能直接用时间范围条件（比如 where create_time >= sysdate - 1）实现真正的增量同步——物化视图的“增量”只认变更日志，不认业务时间字段。
为什么 WHERE 时间条件 ≠ 增量刷新
物化视图的 REFRESH FAST 机制依赖源表上的物化视图日志（MLOG$_xxx）捕获 INSERT/UPDATE/DELETE 操作，它只关心“哪些行被改过”，不关心“这些行的业务时间字段值是多少”。你在 MV 定义里写 WHERE update_time > TO_DATE('2026-06-22', 'YYYY-MM-DD')，只是首次构建或全量刷新时做一次过滤；后续 FAST 刷新仍会拉取所有变更（无论时间戳新旧），再套这个 WHERE 条件裁剪——这既不节省网络/IO，也不保证“只同步昨天新增数据”。
- 真正的时间段增量必须靠源表自身变更日志 + 业务时间字段联合控制，Oracle 原生不支持自动按时间戳分区刷新
- 如果源表没有主键或未建合规日志，
FAST会静默退化为COMPLETE，你根本不知道它没走增量 -
SYSDATE、CURRENT_DATE等动态函数会导致 MV 被标记为不可快速刷新（FAST_REFRESHABLE = 'NO'）
可行方案：用时间戳字段 + 日志 + 手动水位管理
想按时间段同步（例如每天只拉前一日变更），必须人工维护一个“上次同步时间点”，并确保该字段在日志和 MV 查询中都被显式包含：
- 源表需有稳定更新的时间戳字段（如
last_modified），且该字段在每次 DML 时被准确更新 - 建日志时必须含该字段：
CREATE MATERIALIZED VIEW LOG ON t WITH PRIMARY KEY, ROWID (id, last_modified) INCLUDING NEW VALUES; - MV 查询中显式 SELECT 该字段，并在 WHERE 中引用（不能用
SYSDATE）：SELECT id, name, last_modified FROM t@dblink WHERE last_modified > TO_DATE('2026-06-22', 'YYYY-MM-DD') - 每次刷新后，手动更新你的“水位表”（比如一张单行配置表），把
TO_DATE('2026-06-22', ...)替换为新时间——否则下次还拉同样数据
DBMS_MVIEW.REFRESH 执行时的关键参数陷阱
即使你写了带时间条件的 MV，调用 DBMS_MVIEW.REFRESH 时仍可能踩坑：
-
METHOD => 'FAST'不保证真走增量：先查DBA_MVIEWS.FAST_REFRESHABLE，若为NO，说明定义已破坏（比如用了分析函数、漏了日志字段） -
ATOMIC_REFRESH => FALSE必须设为FALSE，否则FAST刷新会清空 MV 再重插，失去“增量”意义 - 别用
START WITH ... NEXT ...自动调度带时间变量的 MV——它无法动态更新 WHERE 中的字面量时间值 - 验证是否真增量：刷新后立刻查
SELECT COUNT(*) FROM MLOG$_t WHERE SNAPTIME$$ > (SELECT LAST_REFRESH_DATE FROM DBA_MVIEWS WHERE MVIEW_NAME = 'MV_T')，结果非零才可信
更稳的做法：放弃 MV 的“自动时间段”，改用分层同步
对严格按时间段同步的场景（如每日 ETL），原生物化视图不是最优工具。推荐组合：
- 源库按
last_modified字段分区或建索引，用DBMS_SCHEDULER调用 PL/SQL 过程，构造动态 SQL 拉取指定时间窗口数据 - 目标库用
MERGE或INSERT /*+ APPEND */+TRUNCATE ... REUSE STORAGE控制写入 - 把时间水位存在
USER_TAB_COMMENTS或独立配置表里，由调度过程读取并更新 - 物化视图只用于“静态快照”或“主键级增量”，别强求它承担业务时间逻辑
真正麻烦的不是写 SQL，而是维护 SNAPTIME$$ 和日志一致性——一旦刷新失败，水位卡住，后续所有增量都错乱，且 Oracle 不报错，只悄悄降级。
