AWR中软硬解析比例需手动计算：硬解析率=parse count (hard)÷parse count (total)，二者取自“Instance Activity Stats”快照差值；Library Cache Hit Ratio高不等于硬解析少，因软软解析仍耗资源；定位绑定变量缺失应查“SQL ordered by Version Count”及dba_hist_sqlstat中version_count>20且loads高、executions_total低的SQL。
怎么看 AWR 里软解析和硬解析比例
awr 报告本身不直接给出“软解析率”或“硬解析率”的百分比，它只统计 parse count (total)、parse count (hard) 和 execute count total 这几个关键指标。你要自己算——别信第三方脚本自动标出的“软解析率 98%”，那往往漏掉了递归 sql 或重复计算。
实操建议：
- 打开 AWR 报告的 “Instance Efficiency Percentages” 部分，找
Parse CPU to Parse Elapsed %（这个反映解析是否被阻塞，不是软硬比） - 翻到 “SQL Statistics” → “SQL ordered by Parse Calls”，看哪些 SQL 的
Parse Calls异常高，再结合执行次数判断是不是没绑定变量 - 真正算硬解析率：用
parse count (hard)÷parse count (total)，这两个值在 “Instance Activity Stats” 表里，注意单位是累计值，要对比两个快照间的差值
Library Cache Hit Ratio 为什么不能说明解析问题
Library Cache Hit Ratio 高（比如 99.5%）不代表硬解析少——它只表示 SQL 文本找到已有 cursor 的比例，而硬解析发生在找不到匹配 cursor 时。但即使命中了，也可能因为 bind mismatch、auth check mismatch 等原因触发软软解析（soft parse with reload），这类解析仍要加锁、校验权限、检查对象有效性，开销不小。
常见错误现象：
- 报告里
Library Cache Hit Ratio> 99%，但latch: library cache等待事件高 - SQL 执行快，但并发一上来就卡在 parse 阶段
- AWR 中
parse count (hard)增长平缓，但parse count (total)暴涨
这时候得查 v$librarycache 的 gethitratio 和 pinhitratio，尤其关注 namespace = 'SQL AREA' 的 pin hit 率；低于 0.99 就值得怀疑有频繁重载。
绑定变量缺失怎么从 AWR 快速定位
没用绑定变量的典型特征是：同一条逻辑 SQL，不同字面量值，生成大量几乎一样的子游标（child cursor）。AWR 不直接列子游标数，但能通过几个间接信号抓出来。
使用场景：业务反馈“某查询突然变慢”，或 DBA 发现 shared pool 内存增长异常快。
实操建议：
- 查 AWR 的 “SQL ordered by Version Count” —— 如果某条 SQL 的
Version Count> 10，基本可以断定存在绑定变量问题（尤其是 where 条件含日期、ID 字符串时） - 结合
dba_hist_sqlstat查历史：运行SELECT sql_id, version_count, executions_total, loads FROM dba_hist_sqlstat WHERE version_count > 20 ORDER BY version_count DESC - 注意
loads高但executions_total低的 SQL，这是“写一次跑一次”的典型痕迹
硬解析多但 Library Cache 命中率不低？可能卡在 mutex 上
Oracle 11g+ 默认用 mutex 替代部分 latch 保护 library cache，如果硬解析多，mutex 竞争会掩盖真实瓶颈。这时候 Library Cache Hit Ratio 看着健康，但实际解析线程在等 cursor: pin S wait on X 或 library cache: mutex X。
性能影响明显：
- 单个硬解析耗时从毫秒级升到几十毫秒，尤其在高并发 OLTP 场景下雪球效应极强
- AWR 中 “Top 5 Timed Events” 出现
library cache: mutex X，且平均等待时间 > 1ms -
v$mutex_sleep_history里对应mutex type = 'Library Cache'的 sleep 多
这时候光改 SQL 加绑定变量不够，还得配合调整 _kks_use_mutex_pin（慎调）、升级到 12c+ 启用 optimizer_adaptive_features 缓解 bind peeking 导致的游标分裂，或者用 SQL Plan Baseline 锁定执行计划减少 reload。
最常被忽略的一点：应用层拼接 SQL 时用了字符串格式化（比如 Python 的 f"WHERE id = {user_id}"），而不是参数占位符（WHERE id = :id）。这种问题不会报错，AWR 里也藏得深，必须代码侧配合审计。
