execute to parse %持续低于90%可初步判断绑定变量使用不佳，需结合sql ordered by parse calls中parse_calls/executions比值>0.8、sql_text含字面量等特征交叉验证。
看 Execute to Parse % 是否持续低于 90%
这个值在 AWR 报告的 Instance Efficiency Percentages 区域，直接反映游标复用效率。它不是“执行一次再解析一次”，而是「每执行 100 次，只解析几次」的倒推值。95% 表示复用良好；80% 就意味着 20% 的执行都触发了解析；若连续几份高峰时段报告都落在 20–40%，基本可锁定是绑定变量大面积缺失。
注意排除干扰：
- 刚重启后该值必然暴跌，属冷启动正常现象
- DBA 工具语句（如
SELECT * FROM v$session）本就不该进共享池，不应计入判断 - 单次报告异常需结合 ASH 看是否由游标失效或子游标爆炸引发
查 SQL ordered by Parse Calls 中 parse_calls / executions 接近 1 的语句
翻到 AWR 报告的 SQL Statistics → SQL ordered by Parse Calls 部分，重点关注那些 parse_calls 和 executions 数值都高、且比值 > 0.8 的 SQL_ID。比如 parse_calls = 12000、executions = 15000，说明几乎每次执行都在重新解析。
拿到 sql_id 后，立刻查 v$sql 验证：
SELECT sql_text, executions, parse_calls FROM v$sql WHERE sql_id = 'xxx'- 若
sql_text中含WHERE id = 123这类字面量，而非WHERE id = :b1，就是铁证 - 若
executions = 1但parse_calls > 1，说明语句反复硬解析后又被挤出共享池，是碎片化信号
用 DBA_HIST_SQLSTAT 算 parse_ratio 排序定位
AWR 不存解析类型标记，但 DBA_HIST_SQLSTAT 有 parse_calls 和 executions 字段，可间接量化复用程度。执行以下查询（替换快照范围）：
SELECT sql_id, sql_text, parse_calls, executions,
ROUND(parse_calls / NULLIF(executions, 0), 2) parse_ratio
FROM dba_hist_sqltext t
JOIN dba_hist_sqlstat s USING (sql_id)
WHERE s.snap_id BETWEEN &begin_snap AND &end_snap
AND s.parse_calls > 50
AND s.executions > 0
ORDER BY parse_ratio DESC, s.parse_calls DESC;
parse_ratio > 0.9 的 SQL 基本等于没重用游标。但要注意过滤掉运维类语句，它们不参与业务逻辑，不该成为优化目标。
验证 force_matching_signature 和 exact_matching_signature 是否分离
这是识别“同一逻辑 SQL、不同字面量拼写”的最可靠方式。在 v$sql 中筛选：
-
force_matching_signature相同但exact_matching_signature不同 - 且重复次数 > 20
- 加上
last_load_time >= to_date('2026-08-26 15:00', 'yyyy-mm-dd hh24:mi')限定问题时段
这类 SQL 就是典型未绑定变量产物。别用 substr(sql_text, 1, 50) 分组——容易把 SELECT * FROM t1 WHERE id = 123 和 SELECT * FROM t2 WHERE name = 'abc' 错误归为一类。
硬解析问题本质是并发争抢，不是 CPU 计算密集。真正卡住的往往不在 SQL ordered by CPU Time 里，而在 latch: library cache 或 latch: shared pool 等待事件背后。指标异常时，必须配合 v$sql_shared_cursor 查具体不共享原因，比如 NLS_LENGTH_SEMANTICS_MISMATCH = 'Y' 或 OPTIMIZER_MISMATCH = 'Y' ——这些细节容易被忽略，却直接决定改写是否真正生效。
