物化视图非实时同步机制，依赖外部信号触发更新而非主动感知DML；REFRESH FAST可能静默降级为COMPLETE，需通过EXPLAIN_MVIEW验证并显式指定FAST避免降级。
物化视图不是实时同步机制，它没有监听主表变更的能力
Oracle 物化视图本身不包含任何触发器、日志订阅或 WAL 解析逻辑。它依赖外部信号（如 DBLINK 连通性、物化视图日志存在性、刷新作业调度）来触发更新，而不是主动感知主表 DML。所谓“只读物化视图”，只是指它不允许直接 INSERT/UPDATE/DELETE，和刷新时效性完全无关。
REFRESH FAST 失败时静默降级为 COMPLETE，你根本不知道
这是最常被忽略的陷阱：你写了 REFRESH FAST ON DEMAND，但只要物化视图日志缺失字段、没建 ROWID 或 SEQUENCE、查询里用了 GROUP BY，Oracle 就会放弃增量逻辑，悄悄执行全量重建（COMPLETE），并锁表、扫全表、重算所有行——而 DBA_MVIEWS.STALENESS 可能仍显示 STALE，LAST_REFRESH_DATE 却长期不动。
- 查是否真走 FAST：
SELECT * FROM TABLE(DBMS_MVIEW.EXPLAIN_MVIEW('MV_NAME'))，重点看RECOMMENDATION字段是否含FAST REFRESHABLE = NO - 强制避免降级：别用
REFRESH FORCE；显式写REFRESH FAST，失败时会报错，不会沉默 - 日志必须覆盖 MV 查询中所有列，包括 JOIN 表里的字段；用
ADD COLUMN补，不要删重建日志
ON COMMIT 模式看似实时，实则不可用于生产核心表
ON COMMIT 确实能在事务提交后立刻刷新，但它要求源表所有 DML 都在同一个事务内完成刷新动作，这会阻塞源库事务提交路径。一旦物化视图所在目标库网络抖动、日志写满或目标表有约束校验失败，源库事务就会卡死。
- 该模式只适合低频、非关键、单点更新的配置类小表（如参数表、状态码表）
- 主业务表一律用
ON DEMAND+ 定时 JOB（如每 5 分钟），配合DBMS_SCHEDULER监控BROKEN状态 -
NEXT时间不能写死成SYSDATE + 1/288（5 分钟），要用NEXT_DAY(SYSDATE, 'MON') + 1/24类表达式防跨天漂移
DBLINK 是单向通道，且不传递事务上下文
物化视图通过 @dblink_name 访问远端表，本质是发起一次独立的远程查询。它拿不到源库的 SCN、无法保证快照一致性，更无法参与两阶段提交。如果源表在刷新过程中被并发修改，物化视图可能读到部分更新状态（类似不可重复读）。
- 源库必须开启补充日志：
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA，否则 FAST 刷新无法识别行变更 - DBLINK 用户权限需最小化：只授
SELECT和SELECT_CATALOG_ROLE，禁用CREATE SESSION以外的高危权限 - 别在物化视图定义里写
SELECT *—— 字段增减会导致刷新失败，错误信息是模糊的ORA-12003
真正影响延迟的从来不是“物化视图慢”，而是你没验证它到底有没有按预期方式刷新。每次上线前，必须手动跑一次 DBMS_MVIEW.REFRESH(..., 'F') 并查 V$MVREFRESH 的 REFRESH_METHOD 字段，确认值是 F 而不是 C。
