db time远超elapsed time属正常并发现象，核心看aas= db time / elapsed time比值是否超cpu核数；若aas=8.5而cpu使用率低且响应正常，说明是高并发非瓶颈，勿误判为排队。
AWR里没有“无效性能指标”这个概念——所有指标都有效，只是你可能误读了它们的含义或使用场景。真正的问题是：哪些指标在特定上下文中会被错误归因为性能瓶颈，从而带偏诊断方向。
DB Time和Elapsed Time比值异常高，但系统响应正常
DB Time远大于Elapsed Time（比如8.5倍），常被当作“严重排队”的铁证。但实际可能是业务并发自然升高，而单条SQL效率没变。
- 先看DB Time / Elapsed是否接近CPU核心数：若为1.2，说明负载轻；若为8.5且CPU使用率
- 查Top 5 Timed Events里db file sequential read的Avg wait ms：如果
- 对比SQL ordered by Executions，确认是不是新增了高频轻量SQL（如心跳、状态轮询），而非原有SQL变慢
Physical Reads高就断定缺索引？
Physical Reads数值大，不等于索引缺失或失效。它只反映数据没在buffer cache里，原因可能是缓存淘汰、大结果集扫描，甚至归档日志刷盘。
- 先看Buffer Hit Ratio：整体>95%时，单条SQL物理读高很可能是首次执行或大表全扫，不是索引问题
- 查DBA_HIST_SEG_STAT，定位具体对象：如果某小表physical_reads暴增，再查对应SQL执行计划是否从INDEX RANGE SCAN退化为TABLE ACCESS FULL
- 注意direct path read等待事件：出现意味着排序/哈希连接绕过了buffer cache，此时加索引无用，应调大pga_aggregate_target或优化SQL逻辑
CPU time占比第一，就认定是SQL问题？
Top 5 Timed Events里CPU time排第一，常让人直奔SQL ordered by CPU Time。但CPU消耗高未必是坏SQL，可能是健康负载上升。
- 看DB Time绝对值：问题时段CPU time为120秒，正常时段为40秒，增长3倍+响应延迟翻倍，才值得深挖
- 查Load Profile里的Execute Count：如果每秒执行次数同步翻倍，说明是流量增长，不是SQL劣化
- 过滤掉module为SQL*Plus、TOAD或JDBC Thin Client的SQL：这些多是人工或测试操作，不代表生产负载
最容易被忽略的是指标背后的采样粒度和统计口径——AWR快照是分钟级聚合，短时尖峰会被抹平；Logical Reads包含索引叶块读取，但Index Leaf Blocks为0未必代表索引失效，可能是函数谓词或统计信息不准导致优化器弃用。真要闭环验证，必须把指标和v$object_usage.USED、DBMS_XPLAN.DISPLAY_AWR、谓词最左前缀匹配三者交叉比对。
