oracle中pl/sql触发硬解析的关键是sql文本字节级不一致：大小写、空格、注释、别名、下划线差异或动态拼接均导致硬解析；静态sql自动绑定变量，动态sql必须用using正确传参，且绑定类型须与列定义严格匹配。
直接用绑定变量就能避免硬解析——前提是 SQL 文本完全一致，且参数类型与列定义匹配。硬解析不是“可以优化”的问题，而是高并发下会立刻拖垮 shared pool 和 latch 的确定性瓶颈。
PL/SQL 里哪些写法会触发硬解析
硬解析只看 SQL 文本是否严格一致：大小写、空格、换行、注释、表别名、甚至末尾分号，全部算在内。Oracle 不做语义等价判断，只做字节级比对。
-
SELECT * FROM emp WHERE deptno = 10和SELECT * FROM emp WHERE deptno = 20是两条不同语句 → 各自硬解析一次 -
SELECT * FROM emp WHERE deptno = :deptno和SELECT * FROM emp WHERE deptno = :dept_no（下划线差异）→ 不共享游标 -
SELECT /*+ INDEX(emp emp_dept_ix) */ * FROM emp和去掉 hint 的版本 → 哈希值不同 → 硬解析 - 动态拼接字符串：
EXECUTE IMMEDIATE 'SELECT name FROM emp WHERE dept_id = ' || v_dept→ 每次生成新文本 → 必然硬解析
静态 SQL 比 EXECUTE IMMEDIATE 更安全
PL/SQL 编译期就确定的 SQL（即静态 SQL），Oracle 自动绑定所有变量，无需额外操作，执行计划最稳定。
- 例如：
SELECT ename INTO l_name FROM emp WHERE deptno = v_dept;→v_dept被自动识别为绑定变量，全程软解析 - 而
EXECUTE IMMEDIATE 'SELECT ename FROM emp WHERE deptno = :d' INTO l_name USING v_dept;才是动态 SQL 的正确绑定写法 - 漏掉
USING子句，或把:d写成' || v_dept，就退化为硬解析 - 静态 SQL 还能享受
session_cached_cursors带来的“软软解析”（PGA 缓存游标），进一步跳过 library cache 查找
绑定变量类型不匹配会导致执行计划失效
即使用了 :x，如果传入值类型和目标列类型不一致，Oracle 可能隐式转换，导致索引失效或执行计划错乱。
-
WHERE status = :status，status列是VARCHAR2(10)，但你传setString(1, "1")是 OK 的；传setInt(1, 1)就触发隐式转换 → 可能走全表扫描 - PL/SQL 中变量声明要贴近实际列类型：
v_status emp.status%TYPE比v_status VARCHAR2(1)更可靠 - 用
TO_NUMBER()或TO_CHAR()显式转换时，务必确认字段统计信息支持该路径，否则 CBO 可能误判
检查硬解析是否真被规避了
不能只看代码写了冒号，得查 v$sql 里实际行为。关键指标是同一 sql_id 下 executions 是否远大于 parse_calls。
- 查疑似未绑定的语句：
SELECT sql_text, executions, parse_calls FROM v$sql WHERE force_matching_signature != exact_matching_signature AND parsing_schema_name NOT IN ('SYS', 'SYSTEM') - 确认某条 SQL 是否复用：
SELECT sql_id, child_number, executions, parse_calls FROM v$sql WHERE sql_text LIKE '%emp%deptno%'—— 如果child_number多个且executions累加，parse_calls增长缓慢，说明软解析生效 - 注意
open_cursors限制：循环中反复OPEN cur FOR ...却不CLOSE，容易触达 ORA-01000，这不是硬解析问题，但常被误认为“绑定没起作用”
真正难的不是写对冒号，而是让所有开发、DBA、ORM 层都对 SQL 文本一致性有共识——一个空格、一个别名、一个 hint 的增减，都可能让缓存失效。这需要从代码规范、SQL 审计、AWR 监控三端同时卡住。
