execute to parse % 为29.76需结合上下文判断：刚重启后偏低属正常冷启动现象；若持续低于40%且parse cpu to parse elapsd %＜20%，则可能因latch: library cache争用导致解析卡顿；长期稳定在30–50%而系统负载正常，多为告警敏感无需干预。
看 Execute to Parse % 是否真低
这个指标在 AWR 报告的 Instance Efficiency Percentages 区域，目标值是 100%，但低于 80% 就该警惕。值为 29.76 不代表“一定有问题”，得结合上下文判断：
- 刚重启实例后出现低值是正常现象——共享池清空，所有 SQL 都要硬解析，
Execute to Parse %必然骤降，此时不是故障而是冷启动过程 - 如果问题时段该值持续低于 40%，且
Parse CPU to Parse Elapsd %也低于 20%，说明解析过程卡在 latch 等待上，而非真正计算，真实瓶颈可能是latch: library cache - 若该值长期稳定在 30–50%，而系统负载不高、响应正常，那只是监控告警敏感，未必需要干预
查硬解析源头：从 v$sql 找未绑定变量的 SQL
AWR 报告本身不直接给出 SQL 文本，得靠 v$sql 视图反查。关键不是看“哪条 SQL 解析最多”，而是看“哪些 SQL 长得像但 signature 不同”——这是未用绑定变量的典型痕迹：
- 用
force_matching_signature和exact_matching_signature对比：force_matching_signature != exact_matching_signature且重复次数 > 20 的，基本就是同一逻辑 SQL、不同字面量拼接出来的 - 避免只截取
substr(sql_text, 1, 50)分组——容易把无关语句误归并；更稳妥的是用 Oracle 官方推荐的remove_constants()函数清洗常量（注意该函数需自行创建） - 过滤条件加
last_load_time >= to_date('2026-07-26 00:00', 'yyyy-mm-dd hh24:mi')，限定在问题时段，否则全库扫太慢
确认是否真由硬解析拖垮 CPU
硬解析率高 ≠ CPU 高，二者可能只是共存，而非因果。必须交叉验证：
- 查 AWR 中
Top 5 Timed Events：如果排第一的是latch: library cache或latch: shared pool，且占比超 30%，那 CPU 消耗实际在争抢闩锁，不是解析逻辑本身 - 看
SQL ordered by CPU Time里有没有单条 SQL 的CPU per Exec突增——如果没这类 SQL，却有大量parse count (hard)，就坐实是硬解析导致的 CPU 毛刺 - 对比正常时段与问题时段的
parse count (hard) / parse count (total)比例：从 2% 升到 15%，才说明硬解析失控；若始终在 8–12%，属于常见业务波动范围
别急着调 cursor_sharing=force
这是最危险的“速效药”。Oracle 12c 默认启用自适应游标共享（ACS），cursor_sharing=force 会绕过 ACS，引发更多副作用：
- 可能导致执行计划固化错误——比如把
WHERE id = 1和WHERE id = 1000000强行共用一个计划，小值走索引、大值却走全表扫描 - 增加
child cursor数量，加剧library cache mutex争用，反而让 CPU 更高 - 某些框架（如 Hibernate 的 native query）或 DBA 工具生成的 SQL 可能含动态 hint，
force模式下无法正确适配 - 真正该优先做的，是定位并改造那几类高频硬解析 SQL：分页查询拼 offset、IN 列表长度不一、日期字符串直写而非绑定
硬解析问题的复杂点在于：它常常是应用层缺陷的镜像，而不是数据库配置缺陷。你看到的 Execute to Parse % 低，背后大概率是几十个微服务里分散的 SQL 拼接逻辑——单靠 DBA 调参数，治标不治本。
