隐式游标仅在确定单行返回时更快，因其跳过游标生命周期管理；多行场景下显式游标更稳更快，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）
SELECT ... INTO，再祈祷数据别出错。 
