为何Oracle 11g存储过程中的隐式游标性能优于显式游标？

隐式游标仅在确定单行返回时更快，因其跳过游标生命周期管理；多行场景下显式游标更稳更快，BULK COLLECT须带LIMIT防内存溢出；游标选择本质是数据契约问题。

SELECT ... INTO 隐式游标在单行场景下确实更快，但这不是“隐式游标整体优于显式游标”，而是**仅限于明确单行、无需循环、不涉及多行处理的特定情况**。一旦脱离这个前提，所谓“性能优势”就不存在，甚至会引发错误或严重劣化。

隐式游标快的前提：必须是单行且确定只返回一行

隐式游标（如 select col into v_var from t where id = :x）快，是因为 oracle 完全跳过了游标生命周期管理：不声明、不打开、不 fetch、不 close，也不分配 pga 内存。执行路径极短，解析后直接走快速路径（fast parse + direct path read）。

• 适用场景：查主键、查唯一约束字段、查配置表固定键值（如 SELECT value INTO v_timeout FROM config WHERE key = 'SESSION_TIMEOUT'）
• 不适用场景：任何可能返回 0 行或 >1 行的查询——会分别报 ORA-01403: no data found 或 ORA-01422: exact fetch returns more than requested number of rows
• SQL%ROWCOUNT 可用，但 SQL%NOTFOUND 不能当循环条件用——它只反映最后一次隐式操作结果，不是游标状态

显式游标在多行场景下不仅不慢，反而更稳更快

把“隐式游标更快”套用到多行遍历上，是常见误解。比如写个循环反复执行 SELECT ... INTO，每轮都硬解析、重新分配上下文、触发 latch 竞争，实际比显式游标慢数倍。

• 显式游标（尤其是 FOR rec IN cursor_name LOOP）底层默认启用 array fetch，一次取 15 行（受 PGA_AGGREGATE_TARGET 影响），大幅减少上下文切换
• 手动控制时用 FETCH c BULK COLLECT INTO t LIMIT 100，可把万行处理耗时从几十秒压到几秒
• 若漏写 CLOSE 或异常路径未处理，会快速耗尽 OPEN_CURSORS 限制，报 ORA-01000

BULK COLLECT 不带 LIMIT 是隐形内存炸弹

很多人以为用了 BULK COLLECT 就一定快，但没加 LIMIT 的写法等价于全量加载，尤其当字段含 VARCHAR2(4000) 或 CLOB 时，极易触发 ORA-04030。

• 单行平均大小 2KB，取 1000 行 ≈ 2MB PGA；并发 10 个会话就吃掉 20MB，远超多数 OLTP 实例默认 PGA 分配
• 实测临界点通常在 100–500 行之间，具体取决于行宽和并发压力
• 必须写成 FETCH c BULK COLLECT INTO t LIMIT 200，且循环内及时清空集合（t.DELETE）

真正容易被忽略的是：**游标类型选择不是语法偏好问题，而是数据契约问题**。你得先确认“这条 SQL 是否保证至多返回一行”，再决定用不用隐式游标；而不是反过来，先写 SELECT ... INTO，再祈祷数据别出错。