awr报告中segments statistics用于识别冗余索引、缺失索引及无效索引，核心依据是segments by logical reads和segments by table scans；需结合sql执行计划、统计信息、分区裁剪等综合判断，避免盲目建删索引。
AWR报告里的Segments Statistics不是用来“建索引”的清单，而是帮你判断“哪些索引该删、哪些表该加、哪些索引根本没被用过”的真实证据源。盲目补索引可能让写性能雪崩，而Segments by Logical Reads和Segments by Table Scans这两块数据，才是索引优化的起点。
Segments by Logical Reads：先揪出真热点，再查SQL关联
高逻辑读的对象（尤其是%Total > 5% 的表或索引）大概率是性能瓶颈载体，但不能直接动手建索引——得先确认是不是SQL本身写法有问题。
- 如果
Object Name是某张大表，且obj Type为TABLE，立刻去SQL Statistics部分按Buffer Gets排序，找出访问它的Top SQL - 检查这些SQL的执行计划：
TABLE ACCESS FULL出现次数多？说明缺索引或索引失效；INDEX RANGE SCAN但Rows估算严重偏高？可能是统计信息过期或隐式转换 - 如果同一张表在
Segments by Table Scans里也排前三，基本坐实了全表扫描泛滥——这时候补索引才有意义，否则只是给IO加负担
Segments by Table Scans：识别未走索引的扫描行为
Segments by Table Scans列出的是被全表扫描次数最多的段。注意：这里统计的是“扫描动作”，不是“慢动作”。哪怕一次扫描很快，扫1000次也会在这里上榜。
- 重点关注
Object Name对应表是否已有索引：dba_indexes里查一下，别重复建 - 若已有索引但依然高频全表扫描，用
DBMS_XPLAN.DISPLAY_CURSOR抓实际执行计划，看是否因WHERE条件含函数、类型转换、OR连用等导致索引失效 - 若该表是分区表，检查是否只扫了单个分区却走了全局全表扫描——可能是分区键未出现在查询条件中，或用了不支持分区裁剪的写法（如
TO_CHAR(partition_col)）
Segments by Physical Reads：区分冷热I/O，避免误判
物理读高 ≠ 索引缺失。它更可能反映缓存不足、大结果集返回、或大量临时段读取（比如direct path read）。直接冲着这个指标加索引，容易南辕北辙。
- 先对比
Segments by Physical Reads和Segments by Logical Reads：如果前者数值远小于后者（比如比例 - 若两者都高，且对象类型是
TEMP或UNDO，优先检查PGA_AGGREGATE_TARGET是否够用、SQL里是否有大排序/哈希连接 - 只有当物理读集中在业务表、且伴随高逻辑读和高Table Scans时，才把索引优化纳入第一优先级
Segments by Unused Indexes：删掉沉默的累赘
AWR默认不直接显示“未使用索引”，但你可以交叉验证：Segments by Logical Reads里找不到某个索引名，而dba_indexes里它又长期存在——大概率是废索引。
- 执行
SELECT index_name, last_analyzed FROM dba_indexes WHERE table_owner = 'YOUR_SCHEMA' AND index_name NOT IN (SELECT object_name FROM dba_hist_seg_stat WHERE object_type = 'INDEX' AND snap_id > (SELECT MAX(snap_id)-10 FROM dba_hist_snapshots))，筛出近10个快照内零逻辑读的索引 - 确认前先查
dba_ind_columns，避免删掉唯一约束或外键依赖的索引 - 删除后观察
Segments by Logical Reads是否整体下降——如果没变化，说明它本来就没被用；如果某些SQL变慢了，说明你漏掉了隐式依赖
最常被忽略的一点：Segments Statistics里的排序是按“累计值”算的，不是“平均每次开销”。一个被调用1万次、每次只读10块的索引，可能比一个调用10次、每次读1万块的表更靠前。优化前务必结合调用频次和单次代价综合判断，否则容易把“高频轻量操作”当成瓶颈猛锤。
