ref cursor 本身不慢，慢的是未关闭、未限数据量、未复用连接或误用场景；性能损耗多发生在 fetch、网络传输、游标滞留等后续阶段，而非执行计划所反映的 open for 阶段。
REF CURSOR 本身不慢，慢的是你没关它、没限制数据量、没复用连接，或者在不该用的地方硬塞进去。
为什么 REF CURSOR 查询变慢但执行计划看起来没问题
执行计划只反映 OPEN FOR 那条 SQL 的优化情况，但 REF CURSOR 的性能损耗常发生在后续阶段：客户端反复 FETCH、网络传输大结果集、游标未及时 CLOSE 导致服务器端资源滞留。尤其当调用方（如 JDBC 或 .NET）用 getResultSet() 后没及时遍历完或没关闭 ResultSet，Oracle 服务端仍维持查询工作区，V$OPEN_CURSOR 里堆积句柄，最终拖垮整个会话甚至实例。
- 检查是否漏掉
ResultSet.close()或 PL/SQL 匿名块里的CLOSE语句 - 确认客户端是否启用了自动 fetch size（如 JDBC 的
setFetchSize(50)），避免一次拉光百万行 - 用
SELECT * FROM V$SESSION WHERE SID = SYS_CONTEXT('USERENV','SID')查当前会话打开的游标数，超限（默认 300）就说明有泄漏
动态 SQL + REF CURSOR 的性能陷阱
用 EXECUTE IMMEDIATE ... OPEN p_cursor FOR 看似灵活，实则绕过 Oracle 的共享池缓存——每次拼接的 SQL 字符串不同，都会生成新游标，硬解析开销陡增。哪怕只是 WHERE dept_id = 10 和 WHERE dept_id = 11，也算两条不同语句。
- 优先改用绑定变量：
OPEN p_cursor FOR 'SELECT * FROM users WHERE dept_id = :dept_id' USING p_dept_id - 完全避免字符串拼接条件，比如不要写
'WHERE status = ''' || p_status || '''' - 若必须动态列或表名，拆成静态主干 + 少量可控拼接，并加
DBMS_SQL缓存校验逻辑
强类型 vs 弱类型 REF CURSOR 对性能没影响，但对稳定性有差别
SYS_REFCURSOR（弱类型）和自定义 REF CURSOR RETURN ...（强类型）在执行效率上无差异，Oracle 内部都走同一套指针机制。但强类型在编译期能校验 SELECT 列与返回结构是否匹配，避免运行时报 ORA-06504: PL/SQL: Return types of Result Set variables or query do not match。
- 对外暴露的存储过程，一律用
SYS_REFCURSOR—— 客户端（JDBC/.NET）只认这个 - 包内模块间传递且结构固定时，可定义强类型，提升 PL/SQL 层可读性
- 别为了“类型安全”强行把一个过程拆成多个强类型出口，维护成本远高于收益
.NET 或 Java 调用时最容易被忽略的三件事
驱动层不显式声明类型，或连接生命周期管理不当，是 REF CURSOR 性能崩塌的高频原因。
-
OracleParameter必须设OracleDbType = OracleDbType.RefCursor，不能靠推断；否则 ODP.NET 会当成普通 OUT 参数，报ORA-06550 - 连接必须保持打开状态直到
ResultSet完全读完并关闭；提前conn.Close()会导致游标句柄失效，FETCH 报Invalid operation for this connection type - 批量调用多个 REF CURSOR 过程时，别复用同一个
OracleCommand实例——参数缓存可能错乱，建议每次新建
真正卡顿的地方，往往不在存储过程里那句 OPEN ... FOR，而在于你忘了关、不敢限、不敢拆、或者调用链某一级悄悄把连接掐断了。
