on commit刷新在每次commit时同步执行merge更新物化视图，共享事务资源并争抢tm锁与行锁，导致高并发下业务变慢；需通过v$transaction、v$locked_object及awr报告闭环定位，禁用query rewrite、拆分mv粒度或改用on demand是有效优化路径。
on commit 刷新会让每次 commit 都触发物化视图维护逻辑，本质是把刷新开销“摊”到每笔业务事务里——不是刷新慢，而是业务变慢了。必须在高并发写入场景下实测，不能只看单次刷新耗时。
ON COMMIT 刷新实际干了什么
Oracle 并非在后台异步执行，而是在你 COMMIT 的那一刻，同步执行一组 DML（通常是 MERGE INTO），去更新物化视图数据。这个操作和你的业务事务共享同一个事务上下文，共用 undo、redo、锁资源。
- 每笔
UPDATE/INSERT/DELETE后的COMMIT，都会触发对物化视图基表（如MV_EMP）的行级修改，争抢该物化视图的 TM 锁和行锁 - 如果物化视图含聚合或连接，
MERGE还需扫描MLOG$_xxx日志表，逻辑读陡增 - 日志表若无索引（比如缺
SNAPTIME$$或变更列上的索引），单次COMMIT可能扫数万行日志 - trace 文件中常见
MERGE INTO "SCOTT"."MV_EMP"占用 90%+ 耗时，而业务 SQL 本身不到 100ms
如何确认是 ON COMMIT 导致卡顿
别只查 v$session_event 看等待，要定位到“谁在等、等什么、等多久”。关键证据链必须闭环：
- 查
v$transaction和v$session：找到status = ACTIVE且sql_id指向MERGE INTO MV_*的会话，prev_sql_id对应你的业务 SQL - 查
v$locked_object：若锁对象是物化视图名（而非基表），且locked_mode是 3（ROW EXCLUSIVE），基本可锁定 - 查 AWR 报告中
Top 5 Timed Foreground Events：若出现大量enq: MV - contention或log file sync突增，说明提交链被拖住 - 对比关闭 MV 前后：用
DBMS_UTILITY.GET_TIME包裹同一条UPDATE + COMMIT，反复执行 100 次取 P95，差值就是纯刷新开销
atomic_refresh=FALSE 在 ON COMMIT 下无效
ON COMMIT 刷新不走 DBMS_MVIEW.REFRESH 接口，因此 atomic_refresh 参数根本不起作用。它强制使用原子事务模型——即所有变更必须在 COMMIT 前完成，否则整个事务回滚。想绕开，只有两个真实可行路径：
- 改用
ON DEMAND+ 定时任务：用DBMS_SCHEDULER创建作业，显式调用DBMS_MVIEW.REFRESH('MV_NAME', method => 'F', atomic_refresh => FALSE)，并绑定RESOURCE_CONSUMER_GROUP控制资源 - 拆分物化视图粒度：把一个大 MV 拆成多个按业务域隔离的小 MV（如
MV_SALES_DAY、MV_SALES_HOUR），降低单次COMMIT的合并压力 - 禁用 QUERY REWRITE：如果业务没强依赖重写，关掉它能省掉优化器检查物化视图可用性的额外开销（
ALTER MATERIALIZED VIEW MV_NAME DISABLE QUERY REWRITE）
统计信息陈旧会放大卡顿感
物化视图刷新后，其段上的统计信息不会自动更新。ON COMMIT 场景下更危险：刚刷完几行，优化器还按百万级旧统计估算，导致后续查询走全表扫描，进一步拉长事务时间，形成恶性循环。
- 刷新后立刻执行：
DBMS_STATS.GATHER_TABLE_STATS('SCHEMA_NAME', 'MV_NAME', cascade => TRUE, estimate_percent => 10) - 不要依赖
AUTO_SAMPLE_SIZE，尤其在高频ON COMMIT场景下，采样耗时可能超过刷新本身 - 若 MV 含分区，务必确认
DBA_TAB_STATISTICS中每个分区的LAST_ANALYZED都已更新，否则分区裁剪失效
真正难处理的不是锁本身，而是“卡顿”没有明显报错：应用层看到的是超时或慢响应，DBA 查 v$session 却只见正常 ACTIVE 状态。必须从 COMMIT 这个动作切入，把物化视图当成业务事务的一部分来压测和监控。
