awr报告不直接区分局部与全局索引扫描，但可通过执行计划、物理读异常及分区剪枝是否生效来判断局部索引是否被有效使用：重点观察top segments中index对象的physical_reads、sql执行计划的partition_start/stop值（all表示剪枝失败）、access_predicates是否含分区键，以及trunc等函数导致的索引失效。
AWR报告本身不直接区分局部索引扫描和全局索引扫描，但能暴露“该索引是否被有效使用”——关键看执行计划是否走索引、物理读是否异常、对应SQL是否在分区剪枝后仍全表扫描。
查Top Segments by Physical Reads识别高I/O索引段
分区表的局部索引在AWR中以独立SEGMENT_NAME出现（如ORDERS_IDX_CREATED），不是按分区名拆开显示。重点盯三列：PHYSICAL_READS、LOGICAL_READS、OBJECT_NAME：
- 若
OBJECT_NAME含INDEX后缀，且PHYSICAL_READS远高于同表其他索引或历史均值，说明该局部索引可能被频繁访问但缓存命中差，或结构失衡 - 若该索引关联的表在
SQL ordered by Physical Reads里反复出现，且对应SQL执行计划是FULL TABLE SCAN而非INDEX RANGE SCAN，基本可判定：局部索引存在，但优化器弃用 - 注意排除
LOBSEGMENT或函数索引——它们在DBA_SEGMENTS中类型不同，需额外确认：SELECT segment_type FROM dba_segments WHERE segment_name = 'YOUR_IDX_NAME'
交叉验证SQL执行计划是否真正利用分区剪枝
局部索引的价值依赖分区键谓词触发剪枝。AWR里看不到剪枝是否生效，但能通过SQL执行计划反推：
- 在
SQL ordered by Elapsed Time中找到高耗时SQL，复制其SQL_ID，执行：SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_AWR('sql_id_here', NULL, NULL, 'ADVANCED')) - 重点看
PARTITION_START和PARTITION_STOP列：若显示具体分区号（如KEY或数字范围），说明剪枝成功；若为ALL，代表扫描全部分区，局部索引形同虚设 - 若执行计划中
ACCESS_PREDICATES不含分区键字段（如ORDER_DATE），而FILTER_PREDICATES里才有，说明剪枝失败，索引未被用于定位分区
警惕TRUNC等函数导致局部索引失效
TRUNC(ORDER_DATE)这类操作会让Oracle无法静态推导分区边界，强制放弃分区剪枝，即使有局部索引也会退化为全表扫描：
- 在
SQL ordered by Executions里找EXECUTIONS突增+PARSE_CALLS同步上升的SQL，再比对PLAN_HASH_VALUE是否突变——若从带INDEX RANGE SCAN变为TABLE ACCESS FULL，大概率是谓词改写引发 - 检查SQL中是否含
TRUNC、TO_CHAR、隐式类型转换等破坏分区裁剪的操作；改写为范围查询（如ORDER_DATE >= DATE '2026-09-01' AND ORDER_DATE ） - 局部索引本身不会因
TRUNC失效，但优化器会因无法估算分区范围而拒绝使用它——这不是索引损坏，是执行计划选择问题
重建局部索引前必须确认约束依赖与并行设置
ALTER INDEX … REBUILD对局部索引影响有限，但若涉及主键/唯一约束，风险陡增：
- 先查依赖：
SELECT constraint_name, constraint_type FROM dba_constraints WHERE index_name = 'YOUR_LOCAL_IDX'；若返回P（Primary Key）或U（Unique），则REBUILD会触发全表约束验证，可能阻塞DML - 局部索引默认继承表级并行度，但若
dba_indexes.degree为1，重建时需显式指定：ALTER INDEX idx_name REBUILD LOCAL PARALLEL 4 - 重建后务必更新统计信息：
DBMS_STATS.GATHER_INDEX_STATS，否则优化器仍可能因CLUSTERING_FACTOR失真而弃用索引
局部索引性能问题 rarely 是索引本身碎片导致，更多是分区剪枝失败、统计信息陈旧、或谓词写法破坏了优化器的分区推导能力。AWR只提供现象线索，真正定位得下钻到执行计划和谓词细节。
