parse cpu to parse elapsed %偏低（如低于20%）说明解析过程被大量等待卡住，cpu实际耗时短但整体耗时长，差值源于library cache mutex或shared pool latch等争用；若execute to parse %持续偏低（如5%）且比值仍低，则可能是解析逻辑复杂而非争用。
Parse CPU to Parse Elapsed %偏低说明什么
这个比值低（比如低于20%），不是CPU解析慢，而是解析过程被大量等待卡住了。CPU实际花在解析逻辑上的时间很短，但整体解析耗时很长——差值就是各种 latch、mutex 等争用导致的排队时间。
常见原因：library cache mutex 或 shared pool latch 争用
当多个会话同时尝试解析新 SQL（尤其是硬解析），必须竞争获取 library cache mutex 或 shared pool latch。一旦争用严重，就会出现：
-
Parse time elapsed显著高于Parse CPU（例如差值 >100 ms/s） - AWR 的 Top 5 Timed Events 中频繁出现
library cache: mutex X或latch: shared pool -
Execute to Parse %持续偏低（如长期 Parse CPU to Parse Elapsed % 同步走低 - 应用端大量字面量 SQL，未使用绑定变量，加剧硬解析并发
为什么不能只看 Parse CPU to Parse Elapsed % 单一数值
这个指标必须和 Execute to Parse %、Parse CPU、Parse time elapsed 四者联动判断：
- 刚重启后
Execute to Parse %必然暴跌（全库硬解析），此时Parse CPU to Parse Elapsed %偏低属正常冷启动现象 - 若
Parse CPU本身很高（如占 DB CPU >5%），但比值仍低，说明解析逻辑复杂（如大量视图展开、递归SQL），而非争用问题 - 比值偶尔 >100% 是统计四舍五入误差，不用处理；但持续
验证与定位的关键操作
别只盯 AWR 报告里的百分比数字，直接查实时争用证据：
- 查当前 latch 争用：
select * from v$latch where name in ('shared pool', 'library cache'); - 查 mutex 等待详情：
select mutex_type, location, sleeps from v$mutex_sleep_history where rownum - 确认硬解析来源：
select sql_id, parsing_schema_name, sql_text from v$sql where loads > 1 and parse_calls > executions;（loads高 +parse_calls > executions是典型硬解析特征） - 检查 NLS 设置是否一致：
select sid, serial#, nls_language, nls_territory from v$session where username is not null;，不一致会强制硬解析
真正难的不是识别这个比值偏低，而是区分它是争用导致的“假性瓶颈”，还是绑定变量缺失引发的“真性硬解析洪流”——这两者修复路径完全不同，混在一起查只会越调越偏。
