wait class 是 oracle 对等待事件按资源争用本质的高层抽象，将数百个事件聚合成十几个类别（如 user i/o、concurrency、on cpu 等），用于快速定位瓶颈；ash 中基于 wait class 分析可过滤噪声、提升聚合稳定性，并支持时间序列趋势追踪，但需注意 on cpu 需显式处理。
wait class 是对等待事件的高层抽象，不是简单归类
oracle 把几百个等待事件（v$event_name 中查到的）按资源类型和业务语义聚合成十几个 wait_class，比如 user i/o、concurrency、commit、on cpu。这不是按字母顺序或事件名拼写做的分组，而是反映底层资源争用本质：一次 db file sequential read 和一次 direct path read 都落在 user i/o 下，因为它们共用磁盘读路径、受相同 i/o 子系统瓶颈影响。
排查时你不需要记住所有 I/O 类事件名，只要看到 WAIT_CLASS = 'User I/O' 占比高，就立刻知道该查存储响应、SQL 执行计划、索引缺失或大表扫描——方向直接，不绕弯。
ASH 中 Wait Class 可快速过滤噪声，聚焦真实瓶颈
ASH 每秒采样一次活动会话，但默认只记录非空闲等待（wait_class != 'Idle'）。如果直接查 V$ACTIVE_SESSION_HISTORY 的原始 EVENT 字段，你会看到大量细粒度事件混在一起：gc current block 2-way、gc cr block busy、enq: TX - row lock contention……单看名字难判断是否同源。
-
WAIT_CLASS = 'Cluster'出现频繁 → RAC 节点间块传输或一致性读压力大，优先检查缓存融合（Cache Fusion）配置和跨节点 SQL -
WAIT_CLASS = 'Application'突增 → 很可能有未提交事务、行锁/表锁、或应用层重试逻辑失控 -
WAIT_CLASS = 'Commit'高 → 不是日志写慢就是提交太频繁，得看log file sync平均等待时间和事务量比值
Wait Class 在 ASH 时间序列分析中提供稳定维度
ASH 数据天然带时间戳（SAMPLE_TIME），按 WAIT_CLASS 分组后做滑动窗口统计（比如每 5 分钟汇总各 Wait Class 出现次数），能清晰看出瓶颈演进过程。而单个等待事件（如 latch: cache buffers chains）可能因 SQL 变更、绑定变量窥探等瞬时出现又消失，难以持续追踪。
实际写查询时，GROUP BY wait_class, TRUNC(sample_time, 'HH') + FLOOR(TO_CHAR(sample_time, 'MI')/10)*10/60/24 这类时间切片逻辑，配合 WAIT_CLASS 聚合，比按 EVENT 聚合更稳定、聚合率更高、结果更易解读。
注意：ON CPU 是特例——它不在 V$EVENT_NAME 中，而是由 session_state = 'ON CPU' 推导而来。ASH 脚本若没显式处理这个分支，查 WAIT_CLASS = 'ON CPU' 会漏掉 CPU 瓶颈，这是最常被忽略的坑。
