Oracle物化视图FAST刷新不使用局部索引，因其依赖物化视图日志和ROWID/主键进行增量合并，直接通过ROWID定位行，完全绕过B-Tree索引（含局部索引）；仅当退化为COMPLETE刷新时，索引才可能被CBO用于全量扫描。
oracle物化视图快速刷新（fast）不使用基表的局部索引，根本原因在于：快速刷新引擎只依赖物化视图日志（mlog$）和基表的 rowid 或主键/唯一键，完全绕过任何 b-tree 索引（包括局部索引），无论该索引是否覆盖 join 列、where 条件或 group by 字段。
REFRESH FAST 不查索引，只读日志和 ROWID
快速刷新的本质是“增量合并”：它从 MLOG$_xxx 表里捞出变更行的 ROWID，再用这些 ROWID 回基表定位具体行，做 INSERT/UPDATE/DELETE。整个过程不走 WHERE、不走 JOIN 条件解析，更不触发索引查找。
-
ROWID是唯一且最高效的定位方式 —— Oracle 内部直接跳转数据块+行号，比任何索引都快一个数量级 - 局部索引（如分区表上的 LOCAL INDEX）只在全表扫描、普通 SQL 查询或
COMPLETE刷新时被优化器考虑 - 即使你在 JOIN 列上建了局部唯一索引，
REFRESH FAST也不会用它 —— 它只关心日志里有没有对应列的SEQUENCE()记录
为什么你看到执行计划里有索引访问？
那不是刷新逻辑本身在用索引，而是 DBMS_MVIEW.EXPLAIN_MVIEW 或后台校验 SQL 在分析可行性时做的模拟查询。这类诊断语句会走正常优化路径，可能选局部索引，但和真实刷新行为无关。
- 真正刷新时，Oracle 强制使用
ROWID路径，哪怕基表是 IOT（索引组织表）且无物理ROWID，也会 fallback 到PRIMARY KEY模式 - 如果你发现某次
REFRESH FAST执行慢，别去调索引，先查DBA_MVIEW_LOGS里ROWIDS = 'Y'是否为真、INCLUDING NEW VALUES是否启用 - 局部索引对刷新性能无正向影响，但若它失效（比如分区索引某个子分区 UNUSABLE），可能导致
EXPLAIN_MVIEW报错，误导你以为是索引问题
局部索引唯一能起作用的场景
仅当物化视图刷新退化为 COMPLETE（或 FORCE 触发 COMPLETE）时，底层重建 SQL 才会像普通 SELECT 一样走 CBO 优化，此时局部索引才可能被选中加速全量扫描。
- 这种情况常见于：日志缺
ROWID、JOIN 列没进SEQUENCE()、用了外连接、基表新增 NOT NULL 列但日志未同步 - 一旦退化，刷新耗时从毫秒级跳到分钟级，
v$session_longops会显示大量 “Table Scan” 或 “Index Fast Full Scan” - 此时优化局部索引有意义，但本质是治标——必须先修复日志结构，让 FAST 恢复可用，否则永远卡在 COMPLETE
真正决定 FAST 能否工作的，从来不是索引是否存在，而是每张基表的物化视图日志是否带 ROWID、是否显式包含所有 JOIN/GROUP BY 列的 SEQUENCE()、以及物化视图定义中是否写了每个基表的 xxx.ROWID xxx_rowid。局部索引只是个旁观者。
