AWR中SQL Parse Time占比超15%表明硬解析泛滥，主因是未使用绑定变量，导致重复语法检查、权限校验和执行计划生成；Parse CPU与Elapsed差值小证实为纯CPU密集型开销，非I/O或锁等待。
AWR里SQL Parse Time占比超15%，基本就是硬解析泛滥，不是SQL慢，是每次都在重复做语法检查、权限校验和执行计划生成。
Parse CPU 和 Parse Elapsd 差值小，说明问题在CPU上
硬解析一次平均吃掉 0.5–2ms CPU。如果每秒有 1000 次执行，其中 90% 没用绑定变量，光解析就占掉 450ms+ CPU 时间。这种情况下，Parse CPU 和 Parse time elapsed 差值很小，说明没卡 I/O 或锁，纯 CPU 被反复烧。
- 查
v$sqlarea：重点关注parse_calls / executions接近 1 的 SQL，比如比值是 0.93 - 看
v$sql.sql_text：找WHERE order_id = 123、AND create_time > '2026-09-28'这类写死值，就是绑定变量缺失的直接证据 - 别信
v$sql_bind_capture为空——它默认关闭，且只捕获最近 15 分钟活跃绑定值；先确认cursor_bind_capture_destination是memory或both
Parse Time 高但 Parse CPU 低，大概率是游标反复进出共享池
比如 Parse CPU to Parse Elapsd % 只有 15%，说明解析本身不耗 CPU，但解析动作太频繁——游标刚缓存进去，马上被挤出去，下次执行又得重新硬解析。
- 检查
session_cached_cursors：默认常为 0 或 20，建议设为 100（需ALTER SYSTEM SET session_cached_cursors = 100 SCOPE=SPFILE+ 重启） - 同步调应用端 PreparedStatement 缓存：Druid 配置
poolPreparedStatements=true和maxPoolPreparedStatementPerConnectionSize（别只设前者） - 别碰
cursor_sharing=force：它会自动把字面量转成:1，但可能改执行计划，引发隐式类型转换或索引失效，bug 比收益多
Load Profile 里 Parse 相关指标异常但 Top SQL 不显眼
单条 SQL 的 Parse Calls 可能不高，但总量吓人。AWR 报告里真正危险的是那些“单次不慢、次次都 parse”的语句。
- 翻到
SQL ordered by Parse Calls，过滤出Module是JDBC Thin Client或SQL*Plus的 SQL——这类基本没走绑定变量 - 看
Version Count：>20 就该警惕，>50 基本确认存在严重游标碎片，常见于TO_CHAR(SYSDATE, 'yyyymmddhh24miss')这种动态拼接 - 注意
Library Cache Hit Ratio>99% 是假象：它只算“找到已有 cursor”的比例，不区分软/硬解析，掩盖了根本问题
最常被忽略的一点：刚重启数据库后 Execute to Parse % 暴跌是正常的，冷启动阶段全库硬解析。别拿首份 AWR 报告当依据，重点看业务高峰段是否持续偏低（低于 40% 就该动手）。优化必须从应用层改 SQL 入手，参数调整只是临时止血，不能替代绑定变量。
