如何解读AWR中的Wait Class_将等待事件归类为应用、并发与配置-Oracle-PHP中文网

wait class 是 oracle 将 100+ 等待事件按责任归属聚类成的十几个逻辑组，用于归因性能问题：application 类指向应用逻辑缺陷，concurrency 类反映数据库内部资源争用，configuration 类暴露配置或硬件瓶颈。

wait class 是什么，为什么不能只看 top 5 event

awr 报告里的 top 5 timed events 看着直观，但单看事件名（比如 enq: tx - row lock contention 或 db file sequential read）容易误判根因。oracle 用 wait class 把 100+ 个等待事件聚类成十几个逻辑组，本质是**按等待背后的责任归属分层**：是应用逻辑写得太猛？是并发控制机制在拦你？还是数据库配置或硬件拖了后腿？wait class 不是统计维度，而是归因线索。

如何从 AWR 报告里定位 Wait Class 分布

打开 AWR 报告，直接翻到 “Wait Classes by Total Wait Time” 小节（通常在 Instance Efficiency Percentages 之后）。这里列出所有非空的 Wait Class 及其总等待时间、占比、平均等待时长。重点关注三类：

Application：说明 SQL 逻辑或事务设计有问题，比如未提交事务占着锁、应用端重试无节制、批量更新没拆分
Concurrency：反映资源争用已突破单会话可控范围，常见于索引块分裂（latch: cache buffers chains）、热点块（buffer busy waits）、序列争用（enq: SQ - contention）
Configuration：指向 DB 参数、存储、内存等基础设置不合理，比如 log file sync 高说明日志写入慢（可能 LGWR 被 I/O 拖住或 commit 过频），db file scattered read 平均时间长可能是磁盘响应差或 buffer cache 不足

Application 类等待的典型表现与验证方法

Application 类事件本身不触发“系统级阻塞”，但会卡住业务流程。关键特征是：等待时间长、单次等待久、常伴随高 DB time 但 CPU 使用率不高。

AI舌诊面诊问诊医疗系统+诊疗商城系统源码

AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。

下载

查具体 SQL：SELECT sql_id, event, p1text, p2text FROM v$active_session_history WHERE wait_class = 'Application' AND sample_time > SYSDATE-1/24 ORDER BY sample_time DESC;
重点盯 enq: TM - contention（外键未建索引）、enq: TX - row lock contention（行锁冲突）、SQL*Net message from client（应用没发 SQL，纯网络或业务逻辑卡住）
注意：如果 SQL*Net message from client 占比异常高，不是数据库问题，而是应用端处理慢或网络延迟大——别调 DB 参数

Concurrency 和 Configuration 的边界在哪

两者容易混淆，判断核心是：**争用是否由数据库内部机制主动引入，且能否通过调整 SQL 或事务行为缓解？**

Concurrency：如 latch: shared pool，说明大量硬解析；改法是绑定变量 + 调整 shared_pool_size，但根因是应用没重用 SQL
Configuration：如 log file switch (checkpoint incomplete)，说明 checkpoint 太慢或 redolog 太小——这和 SQL 写法无关，必须调 fast_start_mttr_target 或加日志组
一个坑：db file sequential read 属于 User I/O 类，但它可能被归为 Configuration（磁盘慢）或 Application（SQL 走全表扫）——得结合执行计划看是不是该走索引却没走