索引优化是否生效，需综合判断db file sequential read耗时、Buffer Gets总量及Buffer Hit Ratio趋势三者是否协同改善，且执行计划中必须出现INDEX RANGE/UNIQUE SCAN并配套TABLE ACCESS BY INDEX ROWID。
看Top 5 Timed Events里db file sequential read是否下降
索引优化最直接的收益，就是减少单块物理读。如果优化前db file sequential read在Top 5中占比超过40%，优化后降到15%以下，基本说明索引生效了。
注意：不能只看占比，还要核对绝对耗时（秒数）。比如优化前该事件耗时210秒，优化后降到35秒，才是真实改善；若只是因为其他等待暴涨拉低了占比，实际耗时仍高，那就没效果。
- 执行计划里出现
INDEX RANGE SCAN或INDEX UNIQUE SCAN才代表走了索引；TABLE ACCESS BY INDEX ROWID是配套动作，缺一不可 - 如果执行计划里有
FULL TABLE SCAN，但db file sequential read反而上升，大概率是索引未被选中，或统计信息过期——先跑DBMS_STATS.GATHER_TABLE_STATS - 虚拟机环境要留意I/O吞吐限制，有时
db file sequential read时间降不下来，不是SQL问题，而是存储层限速
对比SQL Statistics中Buffer Gets和Executions的变化
索引是否真正降低逻辑读，得看Buffer Gets和Executions两个字段的组合变化。单看一个没意义。
例如一条查询原来每执行一次消耗8000逻辑读，每天执行100次 → 总Buffer Gets = 80万。加索引后单次降到120逻辑读，但应用层没改调用逻辑，仍执行100次 → 总Buffer Gets = 1.2万，下降98.5%。这才是有效优化。
- 警惕“单次逻辑读下降但执行次数翻倍”的假象：比如把批量查询拆成100次单行查询，
Buffer Gets/Execution看着漂亮，总负载反而恶化 -
Top SQL by Buffer Gets排序里，同一SQL_ID在优化前后快照中必须严格比对，避免因绑定变量值不同导致执行计划漂移 - 如果
Buffer Gets没变，但CPU Time显著下降，可能是索引减少了排序或哈希计算，属于隐性收益，也要计入效果
检查Instance Efficiency Percentages里的Buffer Hit Ratio
Buffer Hit Ratio从92%升到97%以上，往往意味着索引让热数据更集中、缓存更有效。但这个指标滞后且平滑，不能单独作为判断依据。
它容易掩盖局部恶化：比如某张大表加了索引后Buffer Hit Ratio微升，但另一张高频小表因索引维护开销增大，其块被频繁刷出buffer cache，导致整体命中率虚高。必须结合db block gets和consistent gets绝对值看。
- 若
Buffer Hit Ratio不变甚至略降，但db file sequential read和Buffer Gets都明显下降，说明索引确实起效，只是新索引页本身占用了buffer，短期拉低命中率 -
Library Hit Ratio低于95%时，先别急着归功于索引——硬解析增多会干扰判断，确保所有SQL都用了绑定变量再评估 - SGA_TARGET设置过小会导致buffer cache被迫收缩，此时
Buffer Hit Ratio失真，需同步检查v$sgastat中free memory是否持续低于100MB
用AWRDD做快照间对比，避开平均化陷阱
单张AWR报告里的数字是60分钟聚合值，高峰期的问题会被稀释。比如索引优化前，某SQL在每小时第5分钟集中爆发，耗尽I/O带宽；优化后分布更均匀。单看报告可能觉得“总物理读差不多”，其实体验已大幅改善。
用awrddrpt.sql生成两个时段的差异报告，重点盯Wait Event和SQL Statistics页的“Delta”列，而不是“Total”。Delta体现的是变化量级，不是平均值。
- 差异报告里
db file sequential read的Delta为负值且绝对值大，说明优化见效；若为正值，说明索引引入了额外开销（如过多索引维护、回表成本） - 对比时必须用相同业务周期：比如都是工作日上午9:00–10:00，不能拿优化前的夜间低峰期和优化后的早高峰比
- 如果
direct path read在差异报告中大幅增加，要警惕：索引虽减少了随机读，却引发大量排序或并行查询，把压力转到了临时表空间
db file sequential read耗时、Buffer Gets总量、Buffer Hit Ratio趋势三者是否协同改善。最容易被忽略的是执行计划是否真的用了新索引——哪怕SQL文本一字未改，统计信息不准或直方图缺失，优化器照样会绕过你刚建的索引。 
