显式游标需手动OPEN/FETCH/CLOSE，漏CLOSE致ORA-01000；BULK COLLECT须配LIMIT防OOM；FOR LOOP游标有隐性内存风险；应协同调优open_cursors等参数并关注PGA真实消耗。
显式游标必须手动管理生命周期
oracle pl/sql 中的显式游标不会自动关闭，cursor cursor_name is select ... 只是声明，open、fetch、close 全部要自己写。漏掉 close 是游标泄漏最直接的原因——尤其在异常分支里没做 close，会导致该会话持续持有游标句柄，叠加触发 ora-01000。
常见错误现象包括：存储过程反复执行后查询 v$open_cursor 发现同一游标名重复出现、open_cursors 参数未调大但已接近上限、PGA 内存缓慢上涨。
- 所有
OPEN后必须配对CLOSE，且不能只放在正常流程末尾，要在EXCEPTION块中也写一次 - 避免在循环内反复
OPEN同一游标（比如把OPEN写在FOR循环里） - 用
%ISOPEN判断再CLOSE更安全，例如：IF cursor_name%ISOPEN THEN CLOSE cursor_name; END IF;
批量取数优先用 BULK COLLECT + LIMIT
用 FETCH ... INTO 逐行取，每取一行都是一次上下文切换，慢且容易在长事务中拖住 PGA；而 BULK COLLECT INTO 一次性拉多行进 PL/SQL 表，但若不加 LIMIT，可能把几百万行全 load 进内存，直接 OOM。
正确做法是控制单次提取量，让内存占用可预期：
- 用
FETCH cursor_name BULK COLLECT INTO collection LIMIT 1000，数值按单行平均大小和可用 PGA 估算（通常 100–5000 是安全区间） -
BULK COLLECT后立刻处理并清空集合：collection.DELETE;，否则集合对象持续引用数据，GC 不释放 - 不要对超大结果集用
BULK COLLECT INTO不带LIMIT—— 即使 Oracle 允许，PL/SQL 引擎也会报PLS-00302: component must be declared或静默失败
FOR LOOP 游标看似省事，但有隐性内存风险
FOR rec IN (SELECT ...) LOOP 看似自动管理，实际底层仍会打开游标，并在每次迭代时隐式 FETCH 一行。它不缓存全部结果，这点比无 LIMIT 的 BULK COLLECT 安全，但仍有两个坑：
- 如果循环体里做了耗时操作（如远程调用、写文件、复杂计算），游标会一直保持打开状态，延长服务器端游标占用时间
- 无法控制 fetch size，驱动行为依赖 Oracle 版本和客户端设置，Oracle 19c 后默认行为更激进，可能预取更多行到 PGA
- 不能中断后继续（不像显式游标可记录
%ROWCOUNT），重跑需全量重查
真正需要流式处理且可控时，宁可用显式游标 + BULK COLLECT LIMIT + 显式 COMMIT。
别忽略服务器端游标参数协同
应用层关了游标，不代表 Oracle 立即释放资源。数据库侧还有 open_cursors、session_cached_cursors 和游标老化机制在起作用。
-
open_cursors是硬上限，但调大治标不治本；重点应查v$sesstat中opened cursors current和v$open_cursor找泄漏源头 -
session_cached_cursors缓存已关闭但可复用的游标句柄，设太小会导致频繁软解析；设太大则浪费 PGA；建议值 = 平均并发打开游标数 × 1.5 - 确认是否启用了
cursor_sharing = force，它可能把不同字面量 SQL 归一化，掩盖真实游标爆炸问题
最易被忽略的是：游标本身不占多少内存，但其背后的结果集、排序区、哈希区、LOB 定位器，才是真正吃 PGA 的主力。查 v$sesstat 里的 session pga memory 和 workarea executions – multipass 比盯着游标数更有诊断价值。
