自动索引不作用于物化视图本身，仅优化其依赖的基表；它不参与查询重写决策，也不为物化视图或物化视图日志创建索引，相关索引须手工建立。
自动索引对物化视图本身没有直接加速作用——它不优化物化视图的刷新，也不参与查询重写决策。真正起效的，是自动索引对物化视图所依赖的基表（或底层源表）的索引优化。
自动索引不会给物化视图加索引
物化视图本质是一张物理表（MV_TABLE$ 或用户指定的段），它的访问性能取决于：是否建了合适的索引、是否分区、是否启用查询重写。而 AUTOMATIC INDEXING 机制只识别“普通表”上的列访问模式，从不把物化视图当作索引候选对象。即使你对物化视图执行大量查询，DBA_INDEXES.AUTO 列也永远为 NO，因为 Oracle 明确排除物化视图对象。
常见错误现象包括：DBA_AUTO_INDEX_IND_ACTIONS 中查不到针对物化视图名的索引操作记录；EXPLAIN PLAN 显示扫描物化视图时仍走全表扫描，但自动索引报告里却没提它——这不是漏报，是设计如此。
真正该被自动索引覆盖的是基表
如果你的物化视图定义为 SELECT a.id, a.name, b.amount FROM sales a JOIN orders b ON a.order_id = b.id，那么自动索引真正起作用的地方是 sales 和 orders 这两张基表。只要它们出现在高频 SQL 的 WHERE / JOIN 条件中，且统计信息新鲜，自动索引就可能为 sales(order_id) 或 orders(id) 创建索引，从而加快物化视图的 FAST REFRESH 或查询重写后的基表扫描。
- 确保基表有最新统计信息（
DBMS_STATS.GATHER_TABLE_STATS），否则自动索引跳过该表 - 基表不能是临时表、外部表、IOT 主键溢出段，这些类型不支持自动索引
- 如果物化视图使用
ON COMMIT刷新，基表 DML 频繁，自动索引创建的索引反而可能因维护开销抵消收益
QUERY REWRITE 和自动索引是两条平行线
查询重写（QUERY_REWRITE_ENABLED = TRUE）决定“是否用 MV 替代原查询”，自动索引决定“用哪个索引扫基表”。二者不耦合，也不互相触发。即使自动索引为基表建了完美索引，若 DBMS_MVIEW.EXPLAIN_REWRITE 返回 UNREWRITTEN，查询依然不会走到物化视图上——这时候再好的索引也没意义。
典型干扰点：
-
QUERY_REWRITE_INTEGRITY设为ENFORCED但基表缺RELY ENABLE NOVALIDATE PRIMARY KEY，重写静默失败 - 物化视图定义含
UNION ALL，Oracle 直接拒绝重写（不是索引问题，是语义限制） - 物化视图未
ENABLE QUERY REWRITE，或用户无QUERY REWRITE权限
手动干预比等自动索引更可靠
对物化视图访问路径的优化，优先级应是：先确保查询能重写 → 再为基表建必要索引 → 最后考虑自动索引作为补充。因为：
- 自动索引每 15 分钟才跑一次，且首次运行的 SQL 不参与评估
- 它只建
B-tree索引，无法覆盖函数索引、位图索引等物化视图常用场景 - 它默认不压缩，而物化视图常含大量重复值，
COMPRESS ADVANCED LOW手动建更有效 - 物化视图日志（
MATERIALIZED VIEW LOG）字段必须显式索引，自动索引不会碰这些日志表
最易被忽略的一点：物化视图自身段上的索引，必须手工创建。比如按时间分区的物化视图，CREATE INDEX mv_sales_mth ON mv_sales (sale_month) LOCAL 这类索引，自动索引永远不会生成——它连物化视图表名都过滤掉了。
