物化视图日志（MLOG$_xxx）导致每条DML稳定增加3–15ms延迟，因其同步写入redo、更新索引及分配段空间均属强制事务环节；实测插入10万行耗时从0.21秒升至8.98秒。
物化视图日志（MLOG$_xxx）会让基表每条 INSERT/UPDATE/DELETE 多出 3–15ms 稳定延迟，不是偶发卡顿，而是内核级强制同步写入——只要日志表存在，这个开销就逃不掉。
为什么每次DML都变慢：日志写入是同步事务的一部分
Oracle 不是用触发器模拟日志，而是在 DML 执行路径中硬编码了额外一次 INSERT 到 MLOG$_xxx 表的操作。这个操作和原 DML 绑定在同一事务里，必须等以下三件事全部完成才能返回：
-
redo日志落盘（强制写磁盘，不可绕过） -
MLOG$_xxx表的索引块更新完毕（哪怕只建了一个冗余索引，也会翻倍等待） - 日志表所在表空间完成段分配（若用
MANUAL段管理，高并发下会争用enq: TX - row lock contention）
实测：向一张百万行表插入 10 万行，无日志耗时 0.21 秒；加默认日志后升至 3.73 秒；再启用快速刷新，直接跳到 8.98 秒。
哪些配置会让性能雪上加霜
日志表本身是一张普通堆表，它的性能完全取决于你把它放在哪儿、怎么建、建了哪些索引：
- 表空间选错：混在
USERS或SYSTEM表空间，而非LOCAL + AUTOALLOCATE的专用 SSD 表空间 → IO 争用、递归 SQL 分配区段频繁 - 冗余索引太多：Oracle 默认只建
I_MLOG$_xxx和I_SNAP$_xxx两个索引；多加一个ON (seq$$)就让单条日志插入从 0.2ms 升到 1.5ms+ - 开了
ROW MOVEMENT或COMPRESS FOR OLTP：对日志表毫无收益，反而拖慢INSERT，因为要维护迁移指针或压缩字典
查当前日志表位置：SELECT table_name, tablespace_name FROM user_tables WHERE table_name LIKE 'MLOG$%'；查冗余索引：SELECT index_name, column_name FROM user_ind_columns WHERE table_name LIKE 'MLOG$%' ORDER BY index_name。
紧急降开销的实操动作
别删日志表，先控住写入节奏：
- 临时关闭日志表
REDO：ALTER TABLE MLOG$_xxx NOLOGGING（仅限紧急，之后必须成功执行一次FAST刷新补全状态） - 清积压但不破坏快照时间戳：
EXEC DBMS_MVIEW.PURGE_LOG('BASE_TABLE_NAME')（比TRUNCATE安全） - 重建日志时精简字段：
CREATE MATERIALIZED VIEW LOG ON t1 WITH ROWID (id, status) INCLUDING NEW VALUES—— 只列物化视图 SQL 实际引用的列
INCLUDING NEW VALUES 是双刃剑：它让每条 UPDATE 记两条日志（旧值+新值），日志体积和 REDO 量直接翻倍；除非物化视图定义里真用了 OLD_NEW$ 或需要判断 UPDATING，否则别开。
最常被忽略的一点：日志表的性能瓶颈不在 SQL 层，而在 IO 路径和段管理机制。优化不能只盯着 DBMS_MVIEW 包，得从 dba_tablespaces 和 v$session_event 里挖真实等待事件。
