动态SQL因文本不一致导致library cache无法共享游标：空格、大小写、字面量差异使每条语句生成独立哈希值，即使仅引号位置不同也触发伪软解析；绑定变量误用（拼接表名/列名、类型不一致）引发BIND_MISMATCH，子游标分裂；SESSION_CACHED_CURSORS对动态SQL失效，多会话加剧软解析争用，最终表现为version_count飙升、shared pool膨胀及library cache latch等待。
动态SQL为什么总在library cache里“找不到老熟人”
因为Oracle判断SQL能否复用，第一关就卡在文本完全一致——包括空格、大小写、注释、字面量。动态SQL拼接时稍有不慎，WHERE name = 'Alice' 和 WHERE name = 'Bob' 就是两条不同语句，各自生成独立哈希值，哪怕只差一个引号位置，也进不了同一个父游标。结果就是：每次执行都得走软解析流程（查hash → 比对全文 → 命中已有执行计划），但根本没机会复用——看起来像“软解析”，实则是“伪软解析”，library cache里堆满相似却无法共享的子游标。
绑定变量没用对，等于白加
很多人以为只要写了:bind_var就万事大吉，但常见错误包括：
- 在PL/SQL块里用
EXECUTE IMMEDIATE 'SELECT * FROM t WHERE id = ' || v_id，压根没用绑定变量 - 用
USING传参，但拼接了动态表名或列名（如'SELECT ' || col_name || ' FROM ' || tab_name），这部分无法参数化，导致SQL文本必然不同 - 绑定变量类型不一致：
NUMBER和VARCHAR2传同一个值，触发BIND_MISMATCH，子游标分裂
这些都会让Oracle判定“环境不同”，即使父游标相同，也必须新建子游标——你看到的v$sql.version_count飙升，源头就在这儿。
session_cached_cursors设再大也没用的场景
SESSION_CACHED_CURSORS只对**同一会话内、完全相同的SQL文本**生效，且仅在第三次执行后才触发软软解析。但动态SQL往往满足不了“完全相同”这个前提：
- 每次拼接出的SQL字符串不同 → 连第一次软解析都算不上，更别说进PGA缓存
- 不同会话执行相似动态SQL → 各自维护自己的cursor cache，无法跨session共享
- 设置了
open_cursors但没调高session_cached_cursors→ 软软解析根本不会发生，所有重复执行仍要抢library cache latch
换句话说：动态SQL + 无绑定 + 多会话 = 硬解析压力转移成软解析争用，library cache lock和library cache pin等待事件就会冒头。
怎么一眼看出是不是动态SQL惹的祸
别只盯parse count (hard)，重点看这三个指标：
-
select sql_id, version_count, executions from v$sql where version_count > 20 order by version_count desc—— 高version_count大概率是动态SQL+字面量混用 -
select * from v$sql_shared_cursor where sql_id = '&sql_id'—— 查具体哪条reason拦住了共享，常见BIND_MISMATCH、OPTIMIZER_MISMATCH、TRANSLATION_MISMATCH -
select name, value from v$sysstat where name like '%parse%'—— 如果parse count (total)高但parse count (hard)不高，基本坐实是软解析过载
真正难处理的不是硬解析，而是那些看似“已缓存”、实则每个子游标都在吃内存和latch的动态SQL——它们安静地把shared pool撑胖，直到某次AWR快照里SQL ordered by Version Count突然炸出几百行。
