隐式游标仅在确定单行返回时更快，因其跳过游标生命周期管理；多行场景下显式游标更稳更快，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，再祈祷数据别出错。从数据契约的视角看过去，很多性能隐患和异常风险其实早就在设计阶段埋下了。
