Oracle 19c物化视图无真正实时刷新，仅能通过REFRESH ON COMMIT（单库严限）、FAST REFRESH+高精度调度（分钟级延迟）或直读MLOG$_日志自定义消费逼近低延迟。
Oracle 19c 中没有真正意义上的“实时刷新机制”——物化视图本身不支持事件驱动、毫秒级同步的刷新，所谓“实时”，实际只能逼近为低延迟的快速增量刷新 + 及时调度，且必须满足严苛前提。
REFRESH ON COMMIT 不等于实时，仅限单库且有硬限制
REFRESH ON COMMIT 是最接近“实时”的选项，但它只在事务提交后触发刷新，且存在多个关键约束：
- 必须是单数据库（不能跨 DB Link），否则语法直接报错
ORA-12052 - 所有基表必须已建合规物化视图日志：
WITH PRIMARY KEY, INCLUDING NEW VALUES - 查询中不能含子查询、聚合（
GROUP BY）、ROWNUM、SYS_CONTEXT、SYSDATE等任何破坏确定性的元素 - 若物化视图含连接，所有关联列必须有索引，且连接条件需基于主键/唯一键
- 刷新发生在 COMMIT 时刻，会延长事务响应时间，高并发下可能成为性能瓶颈
一旦违反任一条件，创建时不会报错，但后续 COMMIT 后物化视图数据不会更新，且无任何提示。
FAST REFRESH + 定时调度无法做到实时，但可压到分钟级
当必须跨库或含复杂逻辑时，REFRESH FAST ON DEMAND 是唯一可行路径，但“实时”依赖外部调度精度：
-
NEXT表达式必须返回DATE类型，写成'SYSDATE + 1/1440'（1 分钟后）会静默失败，正确写法是NEXT SYSDATE + 1/1440 -
job_queue_processes必须 ≥ 1（建议设为 1000+），否则 job 积压导致延迟飙升 - 检查 job 是否注册成功：
SELECT what, next_date, broken, failures FROM dba_jobs WHERE what LIKE '%DBMS_MVIEW.REFRESH%'; -
FAILURES > 0表示最近刷新失败，常见原因：权限缺失（对基表仅有SELECT ANY TABLE不够，需显式SELECT）、远端 DB Link 密码过期、MLOG$_ 日志膨胀阻塞 DML
即使配置完美，从源表变更 → 日志写入 → job 触发 → 刷新执行，端到端延迟通常在 30 秒～数分钟，不可控因素多。
真要接近实时？绕过物化视图，直读 MLOG$_ 表做自定义消费
物化视图日志（如 MLOG$_emp）才是真正的增量源，它记录了每条变更的类型、字段、顺序和新旧值。你可以跳过 DBMS_MVIEW.REFRESH，自己解析：
- 确保基表日志启用
INCLUDING NEW VALUES和SEQUENCE()（例如：CREATE MATERIALIZED VIEW LOG ON emp WITH PRIMARY KEY, SEQUENCE(empno, ename, sal) INCLUDING NEW VALUES;） -
MLOG$_表中关键字段：DMLTYPE$$（I/U/D）、OLD_NEW$$（O/N/U）、SEQUENCE$$（严格递增序号）、CHANGE_VECTOR$$（位图标记哪些列被改） - 可用 PL/SQL 或外部程序（Python/Java）定时轮询：
SELECT * FROM mlog$_emp WHERE sequence$$ > :last_seq ORDER BY sequence$$，然后投递到 Kafka / RabbitMQ / HTTP webhook - 注意：
MLOG$_不自动清理，长期运行必须配DBMS_MVIEW.PURGE_LOG，否则日志表膨胀会拖慢 DML 性能甚至锁表
这条路放弃“物化视图”外壳，换来的是完全可控的变更捕获节奏和格式，但代价是失去 Oracle 内置的 SQL 层语义一致性保障（比如 JOIN 结果的原子性）。
真正卡住“实时”落地的，从来不是调度频率，而是子查询、聚合、跨库、权限链路这些隐性断点。很多团队花一周调 NEXT 时间表达式，最后发现根本问题是 EXISTS 子句让 FAST REFRESH 从一开始就被内核禁用——查 DBMS_MVIEW.EXPLAIN_MVIEW 返回的 fastrefreshable = FALSE 比反复试错高效得多。
