mlog$_xxx日志表是基表dml的强制同步写入环节，每条操作均被拖慢几毫秒；其性能瓶颈源于redo强刷、索引随机io、段争用及冗余索引，需迁移至专用ssd表空间、精简索引并禁用row movement和compress。
mlog$_xxx 日志表不是“旁路记录”，而是基表每条 insert/update/delete 的强制同步写入环节——性能下降不是偶发卡顿，是每条 dml 都被稳稳拖慢几毫秒。
MLOG$_xxx 的 INSERT 是事务内同步阻塞操作
Oracle 在基表执行 DML 时，若存在物化视图日志，内核会重写该语句，额外插入一行到 MLOG$_xxx 表，并且必须等这行落盘、索引更新完成、redo 写满才能返回。它不走异步队列，也不批处理。
- 实测：10 万行
INSERT，无日志耗时 0.21 秒；加日志后升至 3.73 秒；再叠加快速刷新，涨到 8.98 秒 - 关键影响点：
-
log file sync等待上升（redo 强制刷盘） -
db file sequential read增多（索引块随机访问） - 高并发下易出现
enq: TX - row lock contention（日志表段争用）
-
日志表所在表空间配置不当会放大延迟
MLOG$_xxx 就是一张普通堆表，它的 IO 效率完全取决于表空间配置。常见错误配置包括：
- 和业务表混放在
USERS或SYSTEM表空间 - 表空间使用
MANUAL段管理方式 → 频繁触发递归 SQL 分配区段 - 缺少
AUTOALLOCATE→ 高并发下区段分配锁争用 - 物理磁盘慢，或与业务数据共享 LUN/SSD → 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 = 'YOUR_TBS';
ALTER TABLE mlog$_orders MOVE TABLESPACE mvlog_tbs;冗余索引让每次 DML 多维护 N 个索引块
Oracle 默认只建两个必要索引：
-
I_MLOG$_xxx（隐式主键索引，基于ROWID） -
I_SNAP$_xxx（加速SNAPTIME$$查询）
但很多人手动加了这些索引：
-
ON (seq$$) -
ON (snaptime$$, dmltype$$) -
ON (snaptime$$) INCLUDE (dmltype$$, old_new$$)
后果：
- 每次向
MLOG$_xxx插入一行，就得同步更新所有索引块 - OLTP 场景下极易引发
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 FOR OLTP 对日志表有害无益
这两项特性在 MLOG$_xxx 上不仅没收益，反而加重开销：
-
ROW MOVEMENT触发行迁移逻辑（哪怕极少更新日志行） -
COMPRESS FOR OLTP引入压缩单元（CU）锁定和解压 CPU 开销
实测启用后，单条插入延迟翻倍以上。
禁用命令：
ALTER TABLE mlog$_xxx DISABLE ROW MOVEMENT;
ALTER TABLE mlog$_xxx NOCOMPRESS;
真正关键的不是“要不要日志”，而是“日志能不能轻量、确定、可预测”——它一旦变成 IO + 索引 + 段管理三重瓶颈，基表 DML 就成了稳定低速状态，而不是某次慢查询能掩盖的问题。
