sys_refcursor无需预定义返回结构，支持任意动态sql结果集，而自定义ref cursor需显式声明结构，维护成本高；声明为out参数后仅open一次、不close、避免未初始化，java调用须正确注册types.ref_cursor并及时关闭resultset。
为什么不用自定义 ref cursor 类型，而选 sys_refcursor
因为 sys_refcursor 是 oracle 预定义的弱类型引用游标，无需提前声明返回结构，能适配任意 select 语句的结果集。你写 open rc for 'select * from emp' 或 open rc for 'select deptno, count(*) from emp group by deptno'，都无需改类型定义——这对动态 sql、多场景复用的存储过程至关重要。
自定义强类型 REF CURSOR（如 TYPE emp_cur IS REF CURSOR RETURN emp%ROWTYPE）虽有编译期校验优势，但一旦结果列变化或跨表查询，就得同步改类型定义，维护成本陡增。多数业务场景中，灵活性优先于静态约束。
SYS_REFCURSOR 在存储过程中如何正确声明和返回
声明时直接用预定义类型，不需 TYPE ... IS REF CURSOR；返回时确保只打开一次、且仅对 OUT 参数赋值：
- 声明方式：在过程参数中写
p_result OUT SYS_REFCURSOR，不是IN OUT（除非真要双向传递） - 必须在
OPEN p_result FOR ...前保证该变量未被打开过，否则报ORA-06511: cursor already open - 不要在过程中
CLOSE p_result—— 关闭责任在调用方（如 Java），否则客户端拿到的是已关闭游标，rs.next()直接返回false - 若逻辑分支可能不执行
OPEN，务必显式赋NULL（如p_result := NULL;），避免客户端拿到未初始化的游标变量引发 NPE
Java 调用时 registerOutParameter 的坑
最常踩的错是把 Types.REF_CURSOR 注册位置搞错，或驱动版本不兼容：
- 注册索引必须严格对应存储过程参数顺序，不是参数名。比如
{call pkg.get_data(?, ?)}中第二个?是游标，就只能用cs.registerOutParameter(2, Types.REF_CURSOR) - 驱动必须用
ojdbc8.jar（对应 JDBC 4.2）或更高，ojdbc6及更早版本不支持Types.REF_CURSOR，会抛java.sql.SQLException: invalid column type - 不能用
cs.setNull(2, Types.OTHER)占位——这会让 Oracle 认为该参数不参与绑定，导致getObject(2)返回null，且无明确错误提示 - 获取结果必须走
(ResultSet) cs.getObject(2)，绝不可用cs.getResultSet()（它只对 Statement 有效）或cs.getString(2)（类型不匹配）
性能关键：fetchSize 和资源释放时机
SYS_REFCURSOR 对应的 ResultSet 默认使用 Oracle 服务端游标，但 JDBC 客户端仍按 fetchSize 批量拉取。不设值时默认是 10，查百万行极易 OOM：
- 拿到
ResultSet后立即调用rs.setFetchSize(500)，数值根据单行大小（字段数、LOB 字段有无）和网络延迟调整，500–2000 是常见安全范围 - 不要调用
rs.last()、rs.getRowCount()或rs.absolute(n)—— 这些会强制驱动把全部结果集从服务器拉到内存 - 必须在
finally块中按顺序关闭：rs.close()→cs.close()→conn.close()；漏关rs会导致 Oracle 服务端游标长期不释放，最终耗尽open_cursors限制 - 连接池环境下，别在
close()前手动conn.commit()或conn.rollback()，除非业务明确需要事务控制——REF CURSOR 本身不参与事务，强行提交反而干扰连接池状态
真正容易被忽略的是：游标变量生命周期由服务端控制，但 JDBC 层的 ResultSet 包装对象一旦被 GC 回收，底层 Oracle 游标未必自动关闭。所以显式 close() 不是可选项，是必须项。
