物化视图日志表（MLOG$_xxx）越积越大是因为Oracle仅通过更新snaptime$$标记日志“已被消费”，从不自动物理删除行；即使所有物化视图已完成快速刷新，历史记录仍保留，导致空间不释放、查询变慢、刷新卡顿。
物化视图日志表（MLOG$_xxx）为什么越积越大
因为 oracle 只更新 snaptime$$ 字段标记日志“已被消费”，从不自动物理删除行。哪怕所有物化视图都完成了快速刷新，mlog$_emp 里的百万条记录仍原封不动躺在表里——空间不释放，查询变慢，后续刷新还可能因排序去重卡住。
确认哪些日志能安全清理
不能只看有没有物化视图存在，必须交叉验证两个视图：
-
SELECT * FROM DBA_REGISTERED_SNAPSHOTS WHERE LOG_OWNER = 'SCHEMA_NAME' AND LOG_NAME = 'MLOG$_TABLE_NAME';—— 若无结果，说明没 MV 正在注册使用该日志 -
SELECT LOG_TABLE, MASTER, ROWIDS, PRIMARY_KEY FROM DBA_MVIEW_LOGS WHERE LOG_TABLE = 'MLOG$_TABLE_NAME';—— 确认该日志未被其他 MV 共享引用
两者都为空，才代表这个日志真正“孤立”。否则任意一个 MV 的 LAST_REFRESH_DATE 比日志中最小 snaptime$$ 还晚，PURGE_LOG 就会失败或漏删。
按分区时间范围批量清理旧日志记录
直接 DELETE FROM mlog$_xxx WHERE snaptime$$ < TIMESTAMP '2024-01-01 00:00:00' 是高风险操作：易锁表、占 UNDO、可能被事务阻塞。推荐用 Oracle 原生过程分批清理：
- 先查出待清理的时间边界：
SELECT MIN(snaptime$$), MAX(snaptime$$) FROM mlog$_xxx; - 调用
DBMS_MVIEW.PURGE_LOG('MASTER_TABLE', 30);—— 数字 30 表示“保留最近 30 天”，自动清理早于该窗口的所有已消费记录 - 若需更细粒度（如只清 2023 年前），可写 PL/SQL 循环调用，每次传入固定天数并
COMMIT，避免长事务
清理后必须做的三件事
删完不是结束，不补这三步，下次刷新照样慢甚至报错：
- 立刻收集统计信息：
DBMS_STATS.GATHER_TABLE_STATS('SCHEMA_NAME', 'MLOG$_TABLE_NAME');，否则优化器仍可能选错执行计划 - 检查并重建复合索引：
CREATE INDEX idx_mlog_snap_seq ON mlog$_xxx (snaptime$$, sequence$$) TABLESPACE fast_io_ts;，这是快速刷新扫描日志的性能命脉 - 确认没有残留高水位线影响：
mlog$_xxx不支持SHRINK SPACE，若空间未回收，只能导出数据 →DROP MATERIALIZED VIEW LOG ON schema.table;→ 重建日志
最常被跳过的其实是索引重建和统计信息更新——日志表体积小了，但没索引+过期统计，刷新时照样全表扫描+磁盘排序。
