物化视图完全刷新触发全表扫描是因为complete refresh语义为丢弃旧数据并重新执行定义查询，不依赖增量机制，仅从基表全量读取；若查询未走索引、统计信息过期或含聚合且无合适索引，优化器必选全表扫描。
物化视图完全刷新为什么会触发全表扫描
因为 complete refresh 的语义就是丢弃旧数据、重新执行定义查询——它不看增量变化，也不依赖日志或快照，只管从头查一遍基表。只要基表没走索引优化的查询路径，刷新时自然全表扫描。
常见错误现象：DBA_MVIEW_REFRESH_TIMES 显示刷新耗时陡增；V$SESSION_LONGOPS 里看到大量 TABLE SCAN 操作；AWR 报告中 db file scattered read 突然飙升。
- 检查物化视图定义里的 SELECT 语句是否能走索引：比如带
WHERE条件但字段没索引，或用了函数（UPPER(col)）、表达式（col + 1）导致索引失效 - 确认基表统计信息是否过期：
DBMS_STATS.GATHER_TABLE_STATS必须在刷新前跑过，否则优化器可能误选全表扫描 - 如果物化视图含聚合（
SUM、COUNT等），且基表无合适组合索引，优化器大概率放弃索引访问路径
如何让 COMPLETE REFRESH 少扫点表
核心不是“禁用全表扫描”，而是让扫描变快、变可控——本质上是帮优化器选对执行计划。
- 给物化视图查询中涉及的
WHERE、JOIN、GROUP BY字段建组合索引，顺序按选择性从高到低排（例如(status, created_date, category_id)） - 避免在刷新查询里写
SELECT *，只查物化视图真正需要的列，减少 I/O 和内存压力 - 用
DBMS_MVIEW.REFRESH调用时显式指定method => 'C'和atomic_refresh => FALSE：后者让刷新先 truncate 再 insert，跳过逐行 delete，大幅降低 undo 和 redo 开销 - 如果基表有分区，确保物化视图查询能利用分区裁剪（比如
WHERE dt >= DATE '2024-01-01'），否则即使有分区也白搭
COMPLETE REFRESH 和 ATOMIC_REFRESH=TRUE/FALSE 的实际差异
这个参数不控制“要不要全扫”，只控制“怎么清旧数据”。但它会显著影响锁行为和性能表现。
-
atomic_refresh => TRUE（默认）：用DELETE FROM mview清空，全程持有 DML 锁，其他会话查该物化视图会被阻塞，且 delete 本身可能慢、产生大量 undo -
atomic_refresh => FALSE：用TRUNCATE+INSERT /*+ APPEND */，锁粒度小（只在 truncate 和 insert 阶段短暂加锁），速度更快，但要求物化视图不能有 ON COMMIT 刷新、不能有未提交的 pending refresh - 注意：
atomic_refresh => FALSE时，若刷新失败，物化视图会变为空——没有中间态保障，得靠外部重试逻辑兜底
为什么有些 COMPLETE REFRESH 看似没扫表，其实扫了两次
Oracle 在某些场景下会隐式多扫一次：比如物化视图定义含 ROWID 或引用了远程表（@dblink），或者开启了 QUERY REWRITE 且基表有复杂视图嵌套，优化器可能为校验一致性额外执行一次基表访问。
- 用
EXPLAIN PLAN FOR BEGIN DBMS_MVIEW.REFRESH(...); END;后查PLAN_TABLE，重点看 ID=1 的操作是不是LOAD AS SELECT，再往上追它的 child operation 是否含多个TABLE ACCESS FULL - 禁用查询重写临时测试：
ALTER SESSION SET QUERY_REWRITE_ENABLED = FALSE，再跑 explain plan，对比执行计划变化 - 远程物化视图刷新必然走全表拉取（
SELECT * FROM t@dblink），无法避免扫描，只能靠 dblink 网络和远端表索引优化
最常被忽略的一点：物化视图日志（MLOG$）是否存在，对 COMPLETE REFRESH 完全没影响——它只服务于 FAST REFRESH。别指望建了日志就能让完全刷新变快。
