确认MLOG$_表HWM悬空需查dba_segments中bytes远大于行数对应空间，且dba_tables中blocks远超实际所需；收缩须先ALTER TABLE ... ENABLE ROW MOVEMENT，再SHRINK SPACE COMPACT，并配对使用atomic_refresh=>FALSE启用并行。
物化视图刷新卡在 MLOG$_xxx 表全表扫描上，不是SQL慢，是高水位线（HWM）悬空导致Oracle仍扫描大量空块——收缩HWM就能立竿见影。
怎么确认MLOG$_表HWM真的悬空了？
别只看行数，SELECT COUNT(*) FROM MLOG$_YOUR_TABLE 返回 0 不代表没空间浪费。必须查真实段大小：
-
SELECT bytes/1024/1024 AS mb FROM dba_segments WHERE segment_name = 'MLOG$_YOUR_TABLE'—— 如果返回几十MB甚至上百MB，但日志行数为0，就是典型HWM悬空 - 再对比
SELECT blocks FROM dba_tables WHERE table_name = 'MLOG$_YOUR_TABLE'，若blocks远大于实际数据所需块数，也印证HWM问题
收缩MLOG$_表HWM的实操步骤
必须按顺序执行，缺一不可：
- 先启用行移动：
ALTER TABLE MLOG$_YOUR_TABLE ENABLE ROW MOVEMENT - 再收缩空间：
ALTER TABLE MLOG$_YOUR_TABLE SHRINK SPACE COMPACT（加COMPACT避免锁表太久） - 收缩后建议立刻收集统计信息：
DBMS_STATS.GATHER_TABLE_STATS('OWNER', 'MLOG$_YOUR_TABLE')
注意：不能跳过 ENABLE ROW MOVEMENT，否则 SHRINK 会报错 ORA-10636: row movement is not enabled。
为什么REFRESH还是慢？可能并行没生效
设了 parallelism => 4 却仍是单线程，大概率是 atomic_refresh 没关：
-
atomic_refresh => TRUE（默认）会让整个刷新包在一个事务里跑，并行进程实际被串行化 - 必须配对使用：
DBMS_MVIEW.REFRESH('mv_name', method => 'F', parallelism => 4, atomic_refresh => FALSE) - 验证是否真并行：
SELECT * FROM v$PX_SESSION，刷新期间应看到多个PX进程；只看到1个说明参数被忽略或降级
FAST刷新退化成COMPLETE的隐蔽信号
调用时传了 method => 'F'，但实际执行的是全量重建——Oracle不报错，只默默退化：
- 执行前必查：
SELECT LOG_TABLE, ROWIDS, PRIMARY_KEY, SEQUENCE, INCLUDING_NEW_VALUES FROM USER_MVIEW_LOGS WHERE MASTER = 'YOUR_TABLE'，五项都得是YES - 用
DBMS_MVIEW.EXPLAIN_MVIEW('MV_NAME')看MSGTXT字段，出现"REFRESH FAST IS NOT POSSIBLE"或"NO LOG ON BASE TABLE"就是根因 - 即使EXPLAIN说“可快刷”，刷新仍慢，问题一定出在日志表本身（比如刚被清过、或有其他MV共享但长期未刷）
真正卡住的地方往往不在SQL写法，而在日志表的物理状态和刷新参数的协同逻辑——HWM悬空+atomic_refresh锁死，是生产环境最常被忽略的组合陷阱。
