物化视图刷新慢的根因通常是日志表HWM悬空、FAST刷新条件不满足或统计信息未更新，需依次检查MLOG空间、USER_MVIEW_LOGS配置及DBA_TAB_STATISTICS时间戳。
刷新跟不上更新，八成是日志表（MLOG$_xxx）膨胀卡住了扫描
物化视图刷新慢，不是因为基表改得快，而是刷新时要全扫日志表——哪怕 mlog$_your_table 里只有几条变更记录，oracle 仍从高水位线（hwm）开始扫。查真实占用：select bytes/1024/1024 as mb from dba_segments where segment_name = 'mlog$_your_table'，如果返回几十 mb 但 select count(*) from mlog$_your_table 是 0 或个位数，说明 hwm 悬空。
收缩方法分两步：ALTER TABLE MLOG$_YOUR_TABLE ENABLE ROW MOVEMENT，再 ALTER TABLE MLOG$_YOUR_TABLE SHRINK SPACE COMPACT。别漏掉行移动启用，否则 SHRINK 直接报错。
日常预防比事后收缩更重要：
- 避免无差别批量更新：比如
UPDATE t SET name = UPPER(name)，应改成WHERE name != UPPER(name)减少无效日志 - 确认所有依赖该日志的物化视图都定期刷新，否则日志不会自动清理
- 若确定无其他 MV 使用该日志，可
DROP MATERIALIZED VIEW LOG ON your_table后重建
你以为在跑 FAST 刷新，其实 Oracle 已悄悄切到 COMPLETE
调用 DBMS_MVIEW.REFRESH('mv_name', 'F') 不等于真走快速刷新。Oracle 静默退化时不报错，只拖慢耗时。关键看日志配置是否达标：
查 USER_MVIEW_LOGS 中对应基表的字段：SEQUENCE 和 PRIMARY_KEY（或 ROWIDS）必须同时为 YES；缺任一，FAST 就失效。聚合类 MV 还必须含 COUNT(*)，否则报 ORA-12004。
执行 DBMS_MVIEW.EXPLAIN_MVIEW('mv_name')，查 MVIEW_EXCEPTIONS 表里的 MSGTXT 字段。出现 "REFRESH FAST IS NOT POSSIBLE" 就是根因，不是参数没设对，是结构不支持。
常见踩坑点：
- 基表有主键，但物化视图 SELECT 列里没显式包含该主键列
- 日志建在错表上（大小写不一致、schema 名漏写）
- 多表 JOIN 场景下，某个基表漏建日志，或日志没包含 JOIN 列
调度器排队 + 并行参数被锁死，刷新作业根本没机会跑
查 DBA_JOBS 或 DBA_SCHEDULER_JOBS，看刷新作业的 NEXT_DATE 是否严重滞后，或 BROKEN 为 TRUE。更隐蔽的问题是 job_queue_processes 参数太小——默认常为 10，若同时有 15 个 MV 刷新任务，实际间隔远超设定值。
parallelism 参数单独设了没用，它必须和 atomic_refresh => FALSE 配对才生效。否则所有并行进程挤在一个事务里等提交，锁、undo、TX 等待全来了，V$PX_SESSION 里永远只看到 1 个 PX 进程。
验证是否真并行：
- 刷新期间查
V$PX_SESSION，应看到多个活跃进程 - 查
V$SESSION_LONGOPS，sofar和totalwork应持续变化，而非始终相等 - 用
DBMS_XPLAN.DISPLAY_CURSOR看执行计划，必须出现PX COORDINATOR或PX SEND
刷新后查询变慢？大概率是统计信息没更新
物化视图刷新只改数据，不更新统计信息。DBA_TAB_STATISTICS.LAST_ANALYZED 时间远早于最近一次刷新时间，就是铁证。优化器仍按旧数据量估算，结果该走索引的走全表扫描，该分区裁剪的扫全部分区。
必须对物化视图名（或预建表名）显式收集：DBMS_STATS.GATHER_TABLE_STATS('SCHEMA_NAME', 'MV_SALES_MONTHLY', cascade => TRUE, estimate_percent => 10, method_opt => 'FOR COLUMNS SIZE 254 CUSTOMER_ID, SALES_MONTH')。
注意两点：
- 不能只收集基表统计——物化视图是独立段，优化器完全不参考基表信息
- 若建在预建表上，
GATHER_TABLE_STATS的第二个参数必须是物理表名，不是 MV 名
