隐式游标仅在单行select into场景下更高效安全；多行处理必须用显式游标for循环，它自动批量提取、减少切换；bulk collect需设合理limit防pga溢出，且异常时须显式关闭游标。
隐式游标并不“总是更高效”——它只在单行、确定性查询场景下更快且更安全；一旦涉及多行处理、循环遍历或需要逐行控制，硬用隐式游标反而显著拖慢性能、甚至直接报错。
隐式游标快的前提：必须是单行 SELECT INTO
隐式游标（如 SELECT ... INTO）的“快”，本质是 Oracle 省掉了游标生命周期管理开销：
— 不声明、不打开、不关闭
— 不分配 PGA 内存用于结果集缓存
— 自动走快速路径（如 index unique scan + single-row fetch）
但它有刚性限制：
— 若查询返回 0 行 → 触发 NO_DATA_FOUND
— 若返回 2 行及以上 → 立刻抛出 ORA-01422: exact fetch returns more than requested number of rows
所以它只适合这些场景：
• 查主键或唯一约束字段（WHERE id = 123）
• 读配置表单条记录（SELECT value FROM config WHERE key = 'timeout'）
• 存在性判断后立即退出（配合 SQL%FOUND）
显式游标 FOR 循环才是多行遍历的默认最优解
很多人误以为“手动 OPEN/FETCH/CLOSE 才叫显式游标”，其实 FOR rec IN cursor_name LOOP 就是显式游标的推荐写法——它既保持语义清晰，又由 Oracle 底层自动做批量提取（array fetch，默认一次取 15 行），大幅减少上下文切换。
对比错误用法：
• 错误：在循环里反复写 SELECT ... INTO（比如按 ID 逐个查）→ 每次都触发硬解析 + 单行 fetch，CPU 和 latch 开销爆炸
• 正确：用一个带 WHERE id IN (...) 的显式游标一次性拉回所有目标行，再用 FOR 循环处理
关键点：
• SQL%ROWCOUNT 在隐式游标中只反映最后一次执行的影响行数，**不能当循环计数器用**
• 显式游标 cursor_name%ROWCOUNT 才能准确反映已 FETCH 的行数
• %NOTFOUND 在隐式游标中无意义（它总在执行完就关闭），别拿它写循环条件
BULK COLLECT 不等于“越 bulk 越好”
有人想靠 FETCH c BULK COLLECT INTO t LIMIT 10000 一步到位，结果内存爆了 —— 这不是游标类型问题，而是 PGA 使用失控。
真实瓶颈常在：
• 单行数据含 VARCHAR2(4000) 或 CLOB 字段 → 100 行就吃掉几十 MB PGA
• 并发会话多，PGA_AGGREGATE_TARGET 有硬上限
• 未设 LIMIT → 全量加载，和不用 BULK 没区别，只是把延迟挪到第一次 FETCH
经验阈值：
• 普通字段（ID/NAME/DATE）：LIMIT 200–500 安全
• 含长文本或嵌套对象：LIMIT 50–100 更稳妥
• 必须在 EXCEPTION 块里加 IF c%ISOPEN THEN CLOSE c;，否则游标泄露会触达 OPEN_CURSORS 限制
真正容易被忽略的，是游标类型选择背后的数据语义：不是语法快慢的问题，而是你到底需不需要“遍历”——需要，就老实用显式游标；不需要，单行查就交给隐式游标。混用或强行降维，只会让错误提前暴露，或者让性能问题藏得更深。
