ON COMMIT刷新必须满足基表有主键或已建物化视图日志，否则报ORA-12014或ORA-12052；即使写REFRESH FORCE ON COMMIT，也仅走FAST路径且不降级COMPLETE，因COMPLETE会阻塞提交。
ON COMMIT 刷新必须满足主键或物化视图日志约束
直接写 ON COMMIT 不等于就能生效——Oracle 会静默降级为 ON DEMAND，甚至报错。关键在于基表是否具备快速刷新所需的元数据支撑。最常见失败原因是基表没主键，或未建物化视图日志。
例如对一张无主键的 SYS_USER 表执行：
CREATE MATERIALIZED VIEW mv_t REFRESH FAST ON COMMIT AS SELECT * FROM SYS_USER;
会立刻报 ORA-12014: 表 'SYS_USER' 不包含主键约束条件。这不是语法错，是刷新能力缺失的硬性拦截。
- 若基表有主键且不涉及复杂连接/分析函数，优先用
REFRESH FAST ON COMMIT，但需先建主键物化视图日志：CREATE MATERIALIZED VIEW LOG ON SYS_USER WITH PRIMARY KEY; - 若基表无主键、或含外连接/聚合/子查询，
FAST不可用，只能退到REFRESH COMPLETE ON COMMIT——注意：这会导致每次COMMIT都全量重跑查询，高并发下可能卡住事务 -
REFRESH FORCE ON COMMIT不推荐：它看似“自动选最优”，实则在FAST不可用时 fallback 到COMPLETE，而你根本不知道何时降级，线上难以监控
ON COMMIT 刷新会拖慢基表 DML 性能
启用 ON COMMIT 后，每个插入/更新/删除操作都必须等物化视图刷新完成才提交成功。这不是后台 job，是同步阻塞。
典型影响场景：
- 基表单次 DML 涉及大量行，而物化视图查询本身较重（如多表 JOIN + GROUP BY），
COMMIT延迟可达秒级 - 高并发批量导入时，多个事务排队刷 MV，形成锁等待链
- 物化视图依赖的基表被频繁修改，但实际查询端极少访问该 MV，纯属“为一致性牺牲性能”
验证方法：在会话中开启 SQL 跟踪，执行一条简单 INSERT 后 COMMIT，看执行计划里是否出现 MVIEW REFRESH 相关步骤及耗时。
手动触发刷新比 ON COMMIT 更可控
多数生产环境其实更适合 ON DEMAND + 定时 job，而非盲目上 ON COMMIT。原因很实在：
- 刷新时机可精确控制（比如避开业务高峰），避免随机卡顿
- 失败可重试：
DBMS_MVIEW.REFRESH('mv_name', 'C')报错后能立刻查USER_MVIEWS.LAST_REFRESH_DATE和LAST_REFRESH_END_TIME定位问题 - 支持批量刷新：
DBMS_MVIEW.REFRESH_ALL_MVIEWS或按依赖关系刷：DBMS_MVIEW.REFRESH_DEPENDENT，运维弹性大 - 权限更清晰：建 MV 用
CREATE MATERIALIZED VIEW权限，刷 MV 用EXECUTE ON DBMS_MVIEW，可分离管控
START WITH / NEXT 时间表达式容易写错
即使放弃 ON COMMIT 改走定时刷新，START WITH 和 NEXT 的时间计算也常出问题。Oracle 不接受字符串格式时间，必须是 date 类型表达式。
错误写法（字符串拼接）：
NEXT TO_DATE('23:00', 'HH24:MI')正确写法（基于当前日期推算）：
NEXT TRUNC(SYSDATE) + 1 + 23/24 -- 明天晚上11点
-
TRUNC(SYSDATE)截断到当日零点，避免因会话时区或 NLS_DATE_FORMAT 导致偏差 - 加
1是“明天”，23/24是“23小时”，合起来就是明晚11点 - 如果要每小时刷一次：
NEXT SYSDATE + 1/24；分钟级：NEXT SYSDATE + 1/1440
真正麻烦的不是语法，而是物化视图刷新任务一旦失败，job 默认不会告警，也不会自动重试——得靠外部监控轮询 USER_JOBS.LAST_DATE 和 FAILURES 字段。
