物化视图日志写入慢主因是MLOG$表DML路径阻塞，需优先检查是否启用ROWID+SEQUENCE日志、添加复合索引、分区并定期purge，且ATOMIC_REFRESH=FALSE仅适用于无聚合/连接的MV场景。
物化视图日志写入慢，本质是MLOG$表DML路径被堵
物化视图快速刷新卡住，90%以上不是因为刷新逻辑本身，而是日志表mlog$的insert/update变慢——主表每条dml都会触发日志记录，若日志表没索引、高并发或未分区，就会在日志写入阶段堆积大量undo和redo，拖垮整体io吞吐。这不是“等它跑完”的问题，而是必须从日志表结构和写入路径入手干预。
给MLOG$加复合索引前，先确认是否真用了SEQUENCE+ROWID
没有WITH ROWID, SEQUENCE建的日志，REFRESH FAST会退化为全量扫描主表，索引再好也白搭。检查方式很简单：
- 查日志定义：
SELECT master, log_table, rowids, sequence FROM user_mview_logs WHERE log_table = 'MLOG$_YOUR_TABLE'; - 若
rowids或sequence列值为NO，必须重建日志：CREATE MATERIALIZED VIEW LOG ON your_table WITH ROWID, SEQUENCE (col1, col2) INCLUDING NEW VALUES; - 重建后立刻执行：
EXEC DBMS_STATS.GATHER_TABLE_STATS(user, 'MLOG$_YOUR_TABLE');——否则优化器可能继续走全表扫描
大分区表场景下，MLOG$必须按时间分区并定期purge
分区表每天增百万级数据，日志表MLOG$若不分区，单表就可能超千万行，DBMS_MVIEW.REFRESH每次都要扫全量日志+排序去重，磁盘排序（TEMP）直接打满。解决路径很明确：
- 建分区日志表（Oracle 12c+）：
CREATE TABLE mlog$_your_table PARTITION BY RANGE (snaptime$$) (...)，再用ALTER MATERIALIZED VIEW LOG ON your_table ADD PARTITION ...绑定 - 禁用自动purge（默认不启用），改用定时任务：
EXEC DBMS_MVIEW.PURGE_LOG('YOUR_TABLE', 7);——保留7天已足够，老日志不清理，snaptime$$范围过滤失效 - 避免在业务高峰调用
PURGE_LOG，它会锁日志表，建议凌晨执行
ATOMIC_REFRESH=FALSE对日志IO的影响被严重低估
这个参数常被当成“提速开关”，但它真正起效的位置是在刷新阶段跳过日志表的二次校验。当ATOMIC_REFRESH=TRUE（默认）时，刷新过程会先读一遍日志、再做一致性校验、最后才更新MV，等于把日志表又扫了一遍；而设为FALSE后，直接truncate MV再append插入，日志只读一次。
但注意：它要求MV定义里不能含聚合、连接、ROWNUM，且刷新期间MV不可用——如果业务依赖MV持续可查，宁可加索引和分区，也不要盲目开这个开关。
