ON COMMIT刷新必须满足基表有主键或已建完备物化视图日志，否则建视图报ORA-12014或ORA-12052；即使写REFRESH FORCE ON COMMIT，也仅走FAST路径且不降级COMPLETE，因COMPLETE会阻塞提交。
ON COMMIT 刷新必须满足主键或物化视图日志约束
直接写 ON COMMIT 不等于就能生效。Oracle 会检查基表是否具备快速刷新前提：要么基表有主键，要么已创建对应 MATERIALIZED VIEW LOG。否则建视图时会报 ORA-12014（“表不包含主键约束”）或 ORA-12052（“无法对表执行快速刷新”）。即使你写了 REFRESH FORCE ON COMMIT，底层仍依赖 FAST 能力——FORCE 在 ON COMMIT 场景下不会 fallback 到 COMPLETE。
- 主键方式最常用：确保基表含
PRIMARY KEY，且 SELECT 中包含该主键列 - ROWID 方式需显式建日志：
CREATE MATERIALIZED VIEW LOG ON table_name WITH ROWID;，且 SELECT 中要显式选table_name.ROWID -
ON COMMIT不支持聚合、JOIN 后无主键推导的复杂查询；如含GROUP BY或多表关联，必须保证最终可唯一标识每行（例如通过基表主键或组合主键）
REFRESH FORCE ON COMMIT 实际走的是 FAST 路径
FORCE 在 ON COMMIT 模式下不是“智能选择”，而是强制要求 FAST 可用。它不会退化为 COMPLETE —— 因为 COMPLETE 刷新无法在事务提交瞬间完成（耗时不可控，会阻塞 COMMIT）。所以如果你看到 REFRESH FORCE ON COMMIT 创建成功，说明 Oracle 已确认能做增量刷新；如果失败，就不是语法问题，而是基表准备不足。
- 不要依赖
FORCE来“兜底”：它在此场景下没有 fallback 行为 - 验证是否真走 ON COMMIT：查
USER_MVIEWS.REFRESH_MODE应为COMMIT，REFRESH_METHOD应为FAST - 事务中修改基表后，不必调
DBMS_MVIEW.REFRESH—— 提交即刷新，但要注意：同一事务内后续 SQL 查该物化视图，看到的就是已刷新结果
常见错误：建了 ON COMMIT 却没生效
现象是基表 COMMIT 后，物化视图数据没变。大概率是以下其一：
- 基表没主键，也没建
MATERIALIZED VIEW LOG，但建视图时用了REFRESH COMPLETE ON COMMIT—— 这条语句本身就会报错，根本建不成功 - 误用了
ON DEMAND语法却以为自动刷新：比如漏写ON COMMIT，只写了REFRESH FORCE，此时默认是ON DEMAND，必须手动刷 - 基表被 TRUNCATE 过：TRUNCATE 是 DDL，绕过日志，导致 FAST 刷新失效；此时需重建日志或改用 COMPLETE + ON DEMAND 定时刷
- 物化视图定义里用了不支持 ON COMMIT 的结构，例如
SYSDATE、子查询含分析函数、或未包含所有基表主键列
一个能跑通的最小可行示例
假设你有带主键的基表 users：
CREATE TABLE users (id NUMBER PRIMARY KEY, name VARCHAR2(50), dept_id NUMBER); INSERT INTO users VALUES (1, 'Alice', 101); COMMIT;
然后创建 ON COMMIT 物化视图：
CREATE MATERIALIZED VIEW mv_users_dept BUILD IMMEDIATE REFRESH FAST ON COMMIT AS SELECT id, name, dept_id FROM users;
验证方式：
- UPDATE users SET name = 'Alicia' WHERE id = 1; COMMIT; → 立即查
mv_users_dept就能看到新值 - SELECT refresh_mode, refresh_method FROM user_mviews WHERE mview_name = 'MV_USERS_DEPT'; → 应返回
COMMIT和FAST
真正容易被忽略的是：ON COMMIT 刷新能力完全绑定于基表结构与日志状态，而不是 CREATE 语句写得有多完整。建完不测试 COMMIT 行为，等于没配对。
