物化视图刷新慢主因是日志表HWM悬空、atomic_refresh未设FALSE导致并行失效，以及调度器配置不当；需收缩MLOG$表、配对设置parallelism与atomic_refresh=FALSE，并检查DBA_JOBS及日志结构完整性。
物化视图刷新慢，八成不是SQL本身的问题，而是日志表膨胀 + 并行参数没生效，或根本没走FAST刷新。
物化视图日志表（MLOG$_xxx）太大，刷新就卡在扫描上
日志表不是“用完即删”，它只在所有依赖它的物化视图都完成刷新后才清理旧记录。一个MV长期不刷，或者多个MV共享同一张基表但刷新节奏不一致，MLOG$_xxx 就会持续膨胀——哪怕当前只有几条变更，Oracle 仍要从高水位线（HWM）开始全扫。
常见现象：执行 DBMS_MVIEW.REFRESH('mv_name', 'F') 耗时几分钟，SELECT COUNT(*) FROM MLOG$_your_table 却返回 0 或个位数。
- 先查真实占用：
SELECT bytes/1024/1024 AS mb FROM dba_segments WHERE segment_name = 'MLOG$_YOUR_TABLE'—— 如果远大于行数，说明 HWM 悬空 - 收缩高水位：对日志表执行
ALTER TABLE MLOG$_YOUR_TABLE SHRINK SPACE COMPACT（需启用行移动：ALTER TABLE MLOG$_YOUR_TABLE ENABLE ROW MOVEMENT） - 避免批量无差别更新：比如
UPDATE t SET name = UPPER(name)会为每行记一条日志；应改写为WHERE name != UPPER(name)，减少无效变更 - 定期清理孤立日志：确认没有其他 MV 依赖该日志后，可
DROP MATERIALIZED VIEW LOG ON your_table再重建
parallelism 参数设了但没提速，其实是被 atomic_refresh 锁死了
设了 parallelism => 4 却还是单线程跑，大概率是 atomic_refresh 还在默认的 TRUE。这个参数不开 FALSE，所有并行进程就得挤在一个事务里等提交，锁、undo、TX 等待全来了。
- 必须配对使用：
DBMS_MVIEW.REFRESH('mv_name', method => 'F', parallelism => 4, atomic_refresh => FALSE) -
atomic_refresh => FALSE后，刷新变成分批提交（如每 5 万行 commit 一次），锁粒度变小，但 MV 在刷新中可能短暂返回新旧混合数据 - 切忌同时设
refresh_after_errors => TRUE：出错跳过批次后，已提交的部分无法回滚，状态不可逆 - 验证是否真并行：查
V$PX_SESSION，刷新期间应看到多个 PX 进程；若只看到 1 个，说明 parallelism 被忽略或降级
你以为在跑 FAST 刷新，其实后台悄悄切成了 COMPLETE
定义里写了 REFRESH FAST，调用也传了 'F'，但实际执行的是全量重建——Oracle 不报错，只默默退化，你只能靠耗时突增或监控发现。
- 核心检查项：
SELECT LOG_TABLE, ROWIDS, PRIMARY_KEY, SEQUENCE, INCLUDING_NEW_VALUES FROM USER_MVIEW_LOGS WHERE MASTER = 'YOUR_TABLE'，SEQUENCE和INCLUDING_NEW_VALUES必须为 YES - 日志列必须严格覆盖物化视图 SELECT 中所有非聚合列（含函数来源列）：比如视图写了
UPPER(ename) AS name，日志里就得有ename，不能只写* - 多表 JOIN 场景下，每个基表都要单独建日志，且各自日志中必须包含参与 JOIN 的列 +
ROWID或主键 - 执行
DBMS_MVIEW.EXPLAIN_MVIEW('mv_name')，再查MVIEW_EXCEPTIONS表，ORA-12052 / ORA-12004 直接定位结构缺陷
调度层压着不跑，比 SQL 慢更致命
刷新作业长期卡在 DBA_JOBS 里，NEXT_DATE 滞后几小时，BROKEN = TRUE，或者 job_queue_processes 设置为 1——这时候调优 SQL 或 parallelism 全是白搭。
- 查作业状态：
SELECT WHAT, NEXT_DATE, BROKEN, FAILURES FROM DBA_JOBS WHERE WHAT LIKE '%dbms_mview.refresh%' -
SHOW PARAMETER job_queue_processes，低于 10 时高并发刷新必排队；12c+ 强烈建议迁移到DBMS_SCHEDULER - 用
DBMS_SCHEDULER创建作业时，务必绑定资源消费者组：attribute => 'RESOURCE_CONSUMER_GROUP', value => 'MV_HIGH_PRIORITY'，否则 CPU 争抢下并行毫无意义 - 避免模糊调度：
REPEAT_INTERVAL => 'FREQ=DAILY'容易延迟；改用精确时间点 + 手动触发链更可控
真正卡住刷新的，往往不是某一行 SQL，而是日志表 HWM、atomic_refresh 和调度器这三处“看不见的墙”。调参前先查 MLOG$_ 大小、DBA_JOBS 状态、USER_MVIEW_LOGS 字段完整性——这三步做完，80% 的“刷新慢”问题就已经定位到根上了。
