latch: shared pool等待高根源是硬解析暴增，尤其未绑定变量sql高频执行；需用ash定位幽灵sql，查v$sql_shared_cursor确认共享游标不匹配原因，而非盲目扩容共享池。
latch: shared pool 等待高，不是共享池内存不够大就能解决的——它本质是多个会话在抢同一把内存访问锁，根源几乎总是硬解析暴增，尤其是未绑定变量的 SQL 在高频执行。
怎么快速定位正在争抢 shared pool latch 的活体 SQL
v$sql 里查不到的“幽灵 SQL”，v$active_session_history（ASH）能抓到。因为很多字面量 SQL 根本没缓存成功，就被 ORA-04031 踢出或刷掉了，但它们在硬解析瞬间一定持有 shared pool latch。
执行以下语句，查最近 1 小时内触发最多 latch: shared pool 等待的 SQL：
SELECT sql_id, sql_opname, event, COUNT(*) cnt FROM v$active_session_history WHERE event = 'latch: shared pool' AND sample_time > SYSDATE - 1/24 GROUP BY sql_id, sql_opname, event ORDER BY cnt DESC FETCH FIRST 10 ROWS ONLY;
对返回的 sql_id，再查它的文本特征：
SELECT sql_text,
CASE WHEN sql_text LIKE '%''%''%' THEN 'has literal' ELSE 'no literal' END has_literal,
parsing_schema_name, executions, loads, invalidations
FROM v$sql
WHERE sql_id = '&input_sql_id';
- 重点关注
sql_text中是否含连续单引号（如WHERE name = 'ALICE'） -
executions低（比如 ≤ 3）、loads高、invalidations多 → 典型“换一个值就重编译” - 如果该
sql_id在v$sql里根本查不到，反而更危险：说明它连缓存都进不去，每次都在硬解析+失败+重试
为什么不能只看 v$sqlarea 或 AWR 总硬解析数
AWR 报告里的“总硬解析次数”只是结果汇总，掩盖了谁在干、怎么干、为什么必须硬解析。
v$sqlarea 的问题更隐蔽：
- 它只记录“曾经进过 shared pool 的语句”，但大量 literal SQL 因为空间不足、hash 冲突或子游标失效，根本没落地就消失了
-
FORCE_MATCHING_SIGNATURE在 Oracle 12c+ 后对某些 NLS 设置或隐式类型转换不敏感，聚类失真 - 用
SUBSTR(sql_text,1,60)分组容易误伤（比如不同业务模块前缀相同），也容易漏掉 where 条件后半段才不同的语句
真正要盯的是：v$sql_shared_cursor 里具体哪一列标了 Y。
例如对疑似语句执行：
SELECT * FROM v$sql_shared_cursor WHERE sql_id = '&input_sql_id' AND (UNBOUND_CURSOR = 'Y' OR EXPLAIN_PLAN_CURSOR = 'Y' OR OPTIMIZER_MISMATCH = 'Y');
常见根因包括：
-
UNBOUND_CURSOR = 'Y'→ 绑定变量未实际传值（JDBC 里setString(1, null)也算） -
OPTIMIZER_MISMATCH = 'Y'→ 应用连接时optimizer_features_enable不一致，或 session 级统计信息过期 -
NLS_MISMATCH = 'Y'→ 同一应用不同连接设置了不同NLS_DATE_FORMAT，导致日期字面量解析路径不同
应用层绑定变量改造的关键实操点
改 SQL 是治本，但改法不对，可能白忙活。
JDBC 场景下常见陷阱：
- 用了
PreparedStatement，但每次执行都conn.prepareStatement(sql)新建对象 → 每次都是新 cursor，等于没绑 - 启用了
statementCacheSize > 0，但 cache key 没包含 schema 或 connection 属性，导致缓存命中率极低 - 批量插入用
addBatch()，但每条语句字面量不同（如INSERT INTO t VALUES (1, 'a')和INSERT INTO t VALUES (2, 'b')）→ 必须统一成INSERT INTO t VALUES (?, ?)
Python cx_Oracle 场景：
- 反复调用
cursor.prepare(sql)而非复用已 prepare 的 cursor → 每次触发一次硬解析 - 使用
arrayvar批量绑定时，若数组长度动态变化，Oracle 可能拒绝重用 cursor（尤其 11g） - 字符串绑定未指定长度（
cursor.setinputsizes(name=50)缺失），Oracle 默认按 2000 字节分配，易引发ORA-04031
别碰这些“伪优化”：
-
ALTER SYSTEM FLUSH SHARED_POOL→ 短期缓解？不，它清空所有 cursor，后续所有 SQL 全部退化为硬解析，雪上加霜 -
CURSOR_SHARING = SIMILAR→ Oracle 11g+ 已废弃，且在复杂谓词下极易生成次优执行计划 - 盲目调大
shared_pool_size→ 碎片更分散，free memory看似够，但最大空闲块，<code>request_misses持续升，说明碎片化已严重
最容易被忽略的两个信号
一是 v$sgastat 里 free memory 的绝对值没意义，要看“最大连续空闲块”是否小于新 cursor 所需空间（通常 10–50KB）。查：
SELECT * FROM v$sgastat WHERE name = 'free memory' AND pool = 'shared pool';
二是 v$latch 的 misses 和 gets 比值。只要 misses/gets > 0.005（即 miss rate > 0.5%），就说明 latch 争用已实质性影响性能——别等它上 AWR Top 5 才动手。
硬解析不是“慢一点”，而是“抢锁 + 分配内存 + 生成执行计划 + 插入 hash bucket”，整条链路串行持锁。哪怕单次只多花 1ms，1000 并发就是 1 秒纯等待。问题不在 shared pool 多大，而在有没有让 Oracle 少做一次硬解析。
