直接删除物化视图不会自动清理其依赖的物化视图日志（MLOG$_表），真正占用空间的是这些未被清理的日志表；确认废弃需交叉验证DBA_REGISTERED_SNAPSHOTS和DBA_MVIEW_LOGS，唯一合规清理方式是执行DROP MATERIALIZED VIEW LOG ON owner.table_name。
直接删掉物化视图本身不会自动清理它依赖的物化视图日志（MLOG$_ 表）和底层存储结构，空间往往卡在 MLOG$_xxx 上——这才是真正吃空间的“废弃物”。
怎么确认物化视图日志是不是废弃的
不能只看物化视图是否存在，Oracle 不会自动删日志，哪怕所有 MV 都被 DROP 了，MLOG$_ 表仍留在数据字典里，持续占空间。
- 查
DBA_REGISTERED_SNAPSHOTS：如果LOG_OWNER和LOG_NAME（如'MLOG$_EMP'）组合查不到记录，说明没 MV 正在注册使用它 - 查
DBA_MVIEW_LOGS：确认该日志的LOG_TABLE没被任何现存 MV 引用（注意：多个 MV 可共享一个日志，得逐个核对MASTER和LOG_TABLE） - 导出当前绑定关系留底：
SELECT LOG_OWNER, LOG_TABLE, MASTER, ROWIDS FROM DBA_MVIEW_LOGS WHERE LOG_TABLE = 'MLOG$_EMP';
绝对不能用 TRUNCATE 或 DROP TABLE 清理 MLOG$_ 表
直接操作 sys.mlog$_xxx 是高危动作，会破坏数据字典一致性，后续建同名 MV 极大概率报 ORA-12003 或刷新失败。
-
TRUNCATE TABLE sys.mlog$_emp→ 高水位线（HWM）下降，但段头块残留旧结构，下次插入可能异常扩展，甚至触发ORA-00604 -
DROP TABLE sys.mlog$_emp→ 数据字典损坏，后续 DDL 可能报ORA-12083（无法删除日志） - 唯一合规路径是走 DDL：
DROP MATERIALIZED VIEW LOG ON owner.table_name;
如果还有活跃 MV 共享日志，只想清旧记录
当部分物化视图长期停用，但其他 MV 还在用同一日志时，可用内置过程精准清理「已被所有活跃 MV 消费」的旧记录，不碰未消费行。
- 执行：
EXECUTE DBMS_MVIEW.PURGE_MVIEW_FROM_LOG('OWNER', 'MLOG$_TABLE_NAME'); - 注意：它只标记/清理已消费记录，不释放物理空间，也不会降低 HWM
- 多 MV 共享日志时，清理边界由最晚的
LAST_REFRESH_DATE决定，不是按单个 MV 判断
真正释放空间的关键动作永远是 DROP MATERIALIZED VIEW LOG，而不是清数据或 shrink；而判断能否删，必须交叉验证 DBA_REGISTERED_SNAPSHOTS 和 DBA_MVIEW_LOGS，漏掉任一检查都可能误删正在被用的日志。
