Oracle中游标不共享主因是硬解析时数十项条件比对失败，须查V$SQL_SHARED_CURSOR视图定位具体Y值原因，如BIND_MISMATCH或OPTIMIZER_MODE_MISMATCH；PL/SQL中应禁用字符串拼接、统一绑定变量类型与长度，并正确使用USING子句，确保SQL文本与执行环境一致以实现共享。
Oracle PL/SQL 中无法也不应“避免游标共享”——真正要解决的是“为什么本该共享的游标没共享”，否则会触发 ORA-01000 或性能劣化。
为什么你看到的游标不共享？查 V$SQL_SHARED_CURSOR 才算数
游标是否共享，不由 PL/SQL 代码显式控制，而是由 Oracle 在硬解析时根据数十项条件比对决定。常见不共享原因包括：OPTIMIZER_MODE_MISMATCH、BIND_MISMATCH、LANGUAGE_MISMATCH 等，全部记录在 V$SQL_SHARED_CURSOR 视图中。
- 执行
SELECT * FROM V$SQL_SHARED_CURSOR WHERE SQL_ID = 'xxx' AND CHILD_NUMBER = 0，看哪一列值为Y - 若
BIND_MISMATCH = Y，说明绑定变量类型或长度不一致（比如:id一次传NUMBER，一次传VARCHAR2(10)） - 若
OPTIMIZER_MODE_MISMATCH = Y，说明会话级设置了不同优化器模式（如ALTER SESSION SET OPTIMIZER_MODE = FIRST_ROWS）
PL/SQL 里最常踩的坑：用字符串拼接代替绑定变量
这是导致子游标爆炸的头号原因。每次拼接出不同 SQL 文本，Oracle 就当它是全新语句，强制硬解析并生成新 child cursor。
- 错例：
OPEN cur FOR 'SELECT * FROM emp WHERE deptno = ' || v_deptno;→ 每次v_deptno不同，SQL 文本就不同 - 正例：
OPEN cur FOR 'SELECT * FROM emp WHERE deptno = :deptno' USING v_deptno;→ 同一 SQL_ID，可复用 child cursor - 注意：
USING后的变量类型必须稳定；若v_deptno有时是NUMBER，有时是CHAR，仍会触发BIND_MISMATCH
REF CURSOR 和隐式游标不参与 shared cursor 共享逻辑
SYS_REFCURSOR 是指针类型，本身不缓存执行计划；它打开的 SQL 是否能共享，取决于其内部 SQL 文本和绑定方式，而非 REF CURSOR 变量本身。
-
OPEN rc FOR SELECT * FROM t WHERE id = :x;→ 这条 SQL 可以共享（前提是绑定一致） -
OPEN rc FOR v_sql_str;（v_sql_str动态拼接）→ 每次都新 SQL，无法共享，且易引发注入和解析压力 - 隐式游标（如
SELECT ... INTO）也走 shared cursor 机制，但因其单行、短生命周期，通常不是瓶颈点
open_cursors 参数不是万能解药
调高 open_cursors 只是缓解 ORA-01000 表象，掩盖了游标未关闭或未共享的根本问题。
- 默认值 1000 是保守设置，生产环境常设为 2000–3000，但超过 5000 需警惕设计缺陷
- 检查当前会话游标占用：
SELECT a.value, b.name FROM v$sesstat a, v$statname b WHERE a.statistic# = b.statistic# AND b.name = 'opened cursors current' AND a.sid = SYS_CONTEXT('USERENV', 'SID'); - 若发现某 PL/SQL 过程反复打开游标却不
CLOSE，即使用了绑定变量，也会耗尽游标句柄资源
真正关键的不是“避免共享”，而是确保每次执行的 SQL 文本、绑定变量类型/长度、优化器环境完全一致——否则 Oracle 别无选择，只能新建 child cursor。这点在动态 SQL 和多租户环境下尤其容易被忽略。
