oracle 11g物化视图刷新后索引未被使用，主因是统计信息未更新、索引状态为unusable或查询谓词不匹配mv索引列；需手动执行dbms_stats.gather_table_stats并指定cascade=>true、重建unusable索引、验证查询是否成功重写到mv。
UNUSABLE，或者查询压根没走这个物化视图。
刷新后 LAST_ANALYZED 时间没变，统计信息滞后
COMPLETE 刷新会重写整张 MV 表，但 Oracle 不自动触发 DBMS_STATS.GATHER_TABLE_STATS。优化器仍按旧的行数、分布直方图估算成本，大概率跳过索引，选全表扫描。
- 查证：运行
SELECT NUM_ROWS, LAST_ANALYZED FROM DBA_TAB_STATISTICS WHERE TABLE_NAME = 'YOUR_MV_NAME'，若LAST_ANALYZED是刷新前时间，就是它 - 修复必须带
cascade => TRUE：否则只更新表统计，不更新索引统计EXEC DBMS_STATS.GATHER_TABLE_STATS(ownname => 'SCHEMA_NAME', tabname => 'MV_NAME', cascade => TRUE); - 11g 默认关闭对物化视图的自动统计收集（
GATHER_STATS_JOB不覆盖 MV），不能依赖自动机制
DBA_INDEXES.STATUS 显示 UNUSABLE
刷新过程中（尤其 ATOMIC_REFRESH = FALSE 或中断发生时），主键/唯一约束可能被隐式 drop，对应索引直接置为 UNUSABLE 状态——此时即使统计正确，优化器也完全跳过该索引。
- 检查命令：
SELECT INDEX_NAME, STATUS FROM DBA_INDEXES WHERE TABLE_NAME = 'YOUR_MV_NAME'，出现UNUSABLE就得重建 - 重建不能靠
ANALYZE或统计收集，必须显式执行：ALTER INDEX idx_name REBUILD; - 预防关键点：刷新时确保
ATOMIC_REFRESH = TRUE（默认值），避免 truncate+insert 脱钩索引
查询谓词不匹配 MV 上的索引列
物化视图索引建在 MV 本身的列上，不是源表。如果查询条件用了函数、别名、表达式，或过滤字段在 MV 定义里被转换过（比如 TO_CHAR(sale_date)），那索引就毫无关系。
- 典型陷阱：
WHERE UPPER(product_name) = 'ABC'—— 即使 MV 有product_name索引，函数调用直接让索引失效 - 更隐蔽的情况：MV 定义中是
TO_CHAR(create_time, 'YYYY-MM')，但查询写create_time >= DATE '2026-01-01'，类型和粒度都不对，无法命中 - 验证是否真走到 MV：
DBMS_MVIEW.EXPLAIN_REWRITE，若返回REWRITE_CANNOT_BE_PERFORMED，说明连 MV 都没重写成功，索引问题反而是次要的
DBA_INDEXES 看到状态是 VALID、也跑了统计收集，却还是走全表扫描——这时候得立刻去看 EXPLAIN PLAN 输出里的 OBJECT_NAME 和 ACCESS_PREDICATES，确认优化器到底在访问哪个对象、用什么条件访问。
