物化视图日志导致dml性能显著下降，因其强制同步写入、依赖io性能、冗余索引加重开销，且row movement与compress反而有害；应使用local+autoallocate专用表空间、仅保留oracle默认两个索引、禁用无关特性。
物化视图日志写入本身就要多一次insert
oracle在基表执行insert/update/delete时，只要该表有物化视图日志（mlog$_xxx），就会额外向日志表插入一条记录——这不是触发器模拟的，而是内核级dml重写逻辑。实测显示：无日志时插入10万行耗时约0.21秒；加日志后升至3.73秒；再配上快速刷新物化视图，直接涨到8.98秒。
关键点在于，这个INSERT不是异步或批处理，它和原DML绑定在同一事务中，必须等日志写完、redo落盘、索引更新完毕才能返回。所以性能下降不是“偶尔卡顿”，而是每条DML都稳稳多出几毫秒开销。
日志表所在表空间IO能力不足会放大延迟
物化视图日志本质就是一张普通堆表（如MLOG$_ORDERS），它的性能完全取决于所在表空间的IO吞吐和段管理方式。常见踩坑是把日志表和业务表混放在USERS或SYSTEM表空间，而这些表空间往往：
- 用的是手动段空间管理（
MANUAL），频繁触发递归SQL分配区段 - 没启用
AUTOALLOCATE，导致高并发下争用enq: TX - row lock contention - 物理磁盘慢，或与业务数据共享同一SSD/LUN，IO被打满
查定位：SELECT table_name, tablespace_name FROM user_tables WHERE table_name LIKE 'MLOG$%'；确认表空间属性：SELECT extent_management, allocation_type FROM dba_tablespaces WHERE tablespace_name = 'XXX'。优先迁移到LOCAL + AUTOALLOCATE的专用SSD表空间。
冗余索引让每次DML都要维护多个索引块
Oracle默认为日志表建两个必要索引：I_MLOG$_xxx（对应ROWID主键）和I_SNAP$_xxx（加速SNAPTIME$$查询）。但很多人会额外加ON (seq$$)或ON (snaptime$$, dmltype$$)——这反而加重DML负担：
- 每次向
MLOG$_xxx插入一行，就得同步更新所有索引块 - OLTP场景下极易出现
db file sequential read和latch: cache buffers chains等待 - 实测显示，多一个冗余索引可使单条日志插入从0.2ms升至1.5ms+
查冗余索引：SELECT index_name, column_name FROM user_ind_columns WHERE table_name LIKE 'MLOG$%' ORDER BY index_name；只保留Oracle自建的两个，其余一律DROP INDEX。
ROW MOVEMENT和COMPRESS对日志表毫无收益
ROW MOVEMENT和COMPRESS FOR OLTP在日志表上不仅没用，反而拖慢INSERT：
-
ROW MOVEMENT会在行迁移或分区维护时触发额外逻辑，而日志表几乎不更新，纯插入场景下完全多余 -
COMPRESS对高频小插入无效：压缩单元（CU）锁定、解压开销、latch争用全部拉高CPU，且日志表数据不可复用，压缩率极低
禁用方法：ALTER TABLE mlog$_xxx NOCOMPRESS; 和 ALTER TABLE mlog$_xxx DISABLE ROW MOVEMENT;。这两项配置在日志表上属于典型“以为有用，实则害人”的操作。
真正影响DML性能的从来不是“有没有日志”，而是日志表是否被当作普通业务表来运维——它需要独立表空间、精简索引、关闭无关特性。否则，每一条INSERT都在替物化视图默默背负三倍以上的IO和CPU成本。
