必须用绑定变量，否则碎片问题无法根治；因未绑定变量的sql被视为不同语句，导致hash bucket链表过长、空闲块细碎分散，引发latch争用与ora-04031，且request_misses上升是碎片化直接证据。
必须用绑定变量，否则碎片问题无法根治。 Oracle 共享池碎片不是内存不够大就能解决的，而是大量字面量 SQL 反复硬解析导致 hash bucket 链表过长、空闲块细碎分散，最终 ORA-04031 会准时报到。
为什么不用绑定变量就一定碎片化？
共享池中每条未绑定的 SQL（比如 SELECT * FROM orders WHERE id = 123 和 SELECT * FROM orders WHERE id = 456）会被视为完全不同的语句，各自分配独立的 shared SQL area。它们不仅挤占空间，更关键的是：
- 都落在同一个 hash bucket 下（尤其当谓词字段基数低、SQL 模板高度一致时），加剧 latch 竞争
- LRU 清理时只淘汰单个 cursor，留下大量 2–5KB 的“空洞”，后续稍大的新 cursor（如带复杂执行计划的 PL/SQL 匿名块）无法复用这些碎片
-
v$sgastat中free memory总量可能不低，但request_misses持续上升——这是碎片化的直接证据
PL/SQL 内部如何安全使用绑定变量？
在 PL/SQL 块里硬拼接字符串（EXECUTE IMMEDIATE 'SELECT ... WHERE id = ' || v_id）等于主动制造碎片。正确做法是：
- 所有动态 SQL 必须用
USING子句传参：EXECUTE IMMEDIATE 'SELECT name FROM emp WHERE deptno = :d' INTO v_name USING v_deptno; - 避免在循环内重复
EXECUTE IMMEDIATE同一模板——改用OPEN ... FOR+FETCH，或提前PREPARE（若用 OCI/cx_Oracle） - 匿名 PL/SQL 块也要绑定：不要写
BEGIN INSERT INTO t VALUES (123); END;，而应写BEGIN INSERT INTO t VALUES (:v); END;并通过调用方传值
哪些 PL/SQL 行为会悄悄放大碎片？
即使用了绑定变量，以下习惯仍会让共享池持续“结痂”：
- 频繁
ALTER SESSION SET optimizer_features_enable或NLS_DATE_FORMAT—— 导致v$sql_shared_cursor中OPTIMIZER_MISMATCH或NLS_MISMATCH为Y，相同 SQL 无法共享 - 过度依赖
session_cached_cursors（比如设成 500），但应用层不真正复用 cursor，只是开一堆长期 idle 的游标，占着 shared pool 不放 - 把大段逻辑塞进一个巨型匿名块（>10KB），每次执行都生成新版本；应拆分为可重用的存储过程，并用
DBMS_SHARED_POOL.KEEP固定 - 在包体中用
PRAGMA SERIALLY_REUSABLE时未清理 package state，残留的私有 SQL 区无法被其他 session 复用
最易被忽略的一点：碎片不是“慢了才修”，而是“只要看到 v$sql 中 EXECUTIONS = 1 且 PARSE_CALLS > 1 的语句批量出现，就说明绑定已失效，碎片正在实时生成——此时查 v$sql_shared_cursor 比调大 shared_pool_size 有用十倍。
