awr中avg wait (ms)是加权平均值，即总等待时间除以等待次数再乘1000，而非简单算术平均；它对io类事件敏感，反映真实负载压力，但需结合直方图、趋势变化及分布形态综合判断性能问题。
awr里avg wait (ms)不是“平均值”而是“加权平均”的结果
很多人误以为Avg Wait (ms)是把所有单次等待时间简单相加再除以次数，其实它是用Total Wait Time（单位秒）除以Waits（等待次数）再乘以1000换算成毫秒——本质上是“总耗时 / 总次数”，即每次等待的等效平均开销。这个数字对IO类事件（如db file sequential read、log file parallel write）特别敏感，因为它们的真实延迟波动大，但总耗时能反映真实压力。
- 如果某次
db file sequential read等待了50ms，另一次只等了1ms，简单平均是25.5ms，但若前者发生了100次、后者只有1次，加权平均会接近49ms——这才是拖慢响应的主力 -
log file parallel write的Avg Wait (ms)长期在2–8ms属正常范围；超过15ms才需怀疑存储，否则大概率是LGWR被频繁唤醒或redo写量突增 - 对于
enq: TX - row lock contention这类锁等待，Avg Wait (ms)意义弱，因为单次锁住可能几秒，但次数少，总耗时未必高——这时要盯Waits / txn和直方图里>4秒的占比
Top 5 Timed Events里的Avg Wait排序掩盖了低频高延时事件
AWR默认按Total Wait Time降序排前5个事件，Avg Wait (ms)只是附带列。这意味着一个发生10次、每次等3000ms的direct path read（总耗时30秒），可能排不进Top 5，但如果它反复出现在直方图的“4 sec to 2 min”区间，就说明PGA不足或临时段爆涨——这种问题光看平均值会漏掉。
- 查
Wait Event Histogram Detail (4 sec to 2 min)，重点看direct path read和log file sync在该区间的出现比例 - 若
log file sync的Avg Wait (ms)是8，但直方图显示20%的等待落在>4秒区间，基本可断定存在提交风暴或IO调度异常 -
db file scattered read的Avg Wait (ms)若>20，再结合Tablespace IO Stats中对应表空间的Av Rd(ms)，才能确认是磁盘慢还是SQL扫了太多块
DB Time与Avg Wait之间没有直接换算关系
DB Time = CPU Time + 所有非空闲等待的总耗时，但它不拆解到每个事件的平均表现。比如DB Time高达437分钟（60分钟快照），但log file parallel write只占其中12分钟，它的Avg Wait (ms)仍可能是性能拐点——因为这12分钟全集中在事务高峰期的几秒内，导致应用端感知到明显卡顿。
- 不要用
DB Time占比反推某个事件是否“严重”：一个只占2%总等待时间的事件，只要Avg Wait (ms)持续>50ms，就足以让OLTP事务超时 - 对比不同快照时，优先看同一事件的
Avg Wait (ms)趋势变化，而非绝对值；比如从5ms跳到18ms，比从18ms降到12ms更值得干预 - ASM或LVM条带配置下，
db file sequential read的Avg Wait (ms)应稳定在5–10ms；若某表空间突然升至25ms，先查dba_hist_iostat_detail确认是不是物理盘故障
真正容易被忽略的是：Avg Wait背后没显示的分布形态。一次200ms的log file sync可能无关紧要，但如果每秒都发生3次，平均下来才15ms，应用却已开始报超时——这时候得翻v$event_histogram，而不是只盯AWR报告里的那个数字。
