物化视图刷新变慢并非由跨年本身触发，而是跨年新增INTERVAL分区导致MLOG$日志条目暴增，叠加日志表缺少(snaptime$$,sequence$$)复合索引及统计信息陈旧，引发全表扫描与磁盘排序。
物化视图刷新变慢是否真由跨年触发？
不是跨年本身导致变慢，而是跨年时新增的 INTERVAL 分区 + 未同步更新的物化视图日志统计信息，共同引发 MLOG$ 全表扫描和排序瓶颈。Oracle 在快速刷新时会扫描整个物化视图日志表（MLOG$_xxx），而新增分区常伴随大量 DML，日志条目暴增；若日志表缺少 (snaptime$$, sequence$$) 复合索引或统计信息陈旧，优化器就会选错执行计划——全表扫描 + 磁盘排序，耗时从秒级升至小时级。
INTERVAL 分区下物化视图日志为何容易失效
INTERVAL 分区表建日志时，CREATE MATERIALIZED VIEW LOG 必须显式指定分区键列（如 CREATED_DATE），否则日志无法捕获新分区的变更。常见错误是只建了 WITH ROWID, SEQUENCE，却漏掉 INCLUDING NEW VALUES 和关键列声明：
-
CREATE MATERIALIZED VIEW LOG ON sales_tab WITH ROWID, SEQUENCE(created_date) INCLUDING NEW VALUES;✅ 正确：含分区键且启用新值 -
CREATE MATERIALIZED VIEW LOG ON sales_tab WITH ROWID;❌ 错误：无 sequence、无分区键、不捕获新分区数据 - 基表新增分区后，日志表
MLOG$_SALES_TAB的OBJECT_ID不自动更新，需确认SELECT master_object_id FROM dba_mview_logs WHERE log_table = 'MLOG$_SALES_TAB'与基表dba_objects.object_id一致
刷新卡在 MLOG$ 扫描阶段怎么快速解
直接定位并修复日志表访问路径，别等自动任务：
- 立刻建复合索引：
CREATE INDEX idx_mlog_snap_seq ON MLOG$_SALES_TAB (snaptime$$, sequence$$);（顺序不能颠倒） - 强制全采样更新统计：
EXEC DBMS_STATS.GATHER_TABLE_STATS(user, 'MLOG$_SALES_TAB', estimate_percent => 100);（默认 AUTO_SAMPLE_SIZE 在百万级日志上极易误判） - 清理过期日志：
EXEC DBMS_MVIEW.PURGE_LOG('SALES_TAB', 7);（保留 7 天足够，避免日志膨胀） - 验证是否生效：查
SELECT COUNT(*) FROM MLOG$_SALES_TAB WHERE snaptime$$ > SYSDATE - 1;，若结果远小于总行数，说明 purge 生效；再跑一次EXPLAIN PLAN FOR BEGIN DBMS_MVIEW.REFRESH('MV_SALES'); END;，看执行计划中是否出现INDEX RANGE SCANonI_MLOG$_SALES_TAB
ATOMIC_REFRESH=FALSE 能不能开？
必须开，但仅限于跨年首次刷新或大分区刷新场景。INTERVAL 分区新增后，第一次快速刷新往往要处理积压日志，此时 ATOMIC_REFRESH => TRUE 会强制事务包住全部操作，undo 表空间易满、锁表时间长、还可能触发 ORA-01555。
开的代价很具体：刷新过程中物化视图短暂为空，下游查询若没加空结果兜底逻辑，会直接报 ORA-01403。所以真正关键的不是“要不要开”，而是“有没有配套的应用层容错”——比如双读逻辑（先查 MV，查不到则 fallback 到基表）或业务低峰期窗口内执行。
