应使用BULK COLLECT + FORALL替代逐行FOR循环，因其避免PL/SQL与SQL引擎频繁上下文切换、提升I/O并行性、减少CPU开销；错误用法会导致ORA-06502、ORA-01403等异常及性能劣化。
别用逐行 FOR 循环处理结果集，直接换成 BULK COLLECT + FORALL，否则 90% 的执行时间都耗在 PL/SQL 和 SQL 引擎来回切换上。
为什么逐行 FOR 循环在 Oracle 里特别慢
每次 FETCH 一行、UPDATE 一行，都要完整走一遍解析 → 执行 → 获取流程。这不是“慢一点”，而是把本可并行的 I/O 强行串行化，Buffer Cache 和索引几乎失效。
- 实测：10 万次循环，CPU 时间 70% 花在上下文切换上
-
SQL_TRACE显示解析时间占比超 30%，实际业务逻辑不到 5% - 等待事件里频繁出现
PL/SQL lock timer或PGA memory operation
怎么把 FOR 循环改成高效批量处理
核心是把控制权从 PL/SQL 层交还给 SQL 引擎，用数组做中转站：
- 声明嵌套表类型：
TYPE data_tab IS TABLE OF your_cursor%ROWTYPE（别用VARRAY或关联数组） -
BULK COLLECT INTO必须带LIMIT 1000，否则大结果集直接触发ORA-04030 -
FORALL i IN 1..v_data.COUNT下标必须连续；若删过元素，改用INDICES OF v_data -
FORALL里不能调用函数（如UPPER(v_data(i).name)），所有转换必须提前算好 - 更新条件优先用
ROWID：WHERE rowid = v_data(i).rid比WHERE id = v_data(i).id更稳
容易踩的坑和对应修复点
这些错误不报语法错，但一跑就崩或静默失败：
-
ORA-06502：集合字段长度不匹配（比如VARCHAR2(10)字段塞了 15 字节值），或集合为空却没判v_data.COUNT = 0就进FORALL -
ORA-01403：用了FORALL ... SAVE EXCEPTIONS却没立刻查SQL%BULK_EXCEPTIONS.COUNT，导致异常被忽略后下一条继续报错 - 误用
%NOTFOUND判断BULK COLLECT结束——它只对单行FETCH有效，必须用v_data.COUNT = 0 - 单次
BULK COLLECT超 5 万行且 PGA 受限（如 OLTP 系统限制 256MB），反而引发磁盘交换；此时仍要分批，但每批坚持LIMIT 1000 + FORALL
什么时候不该强行套 BULK COLLECT + FORALL
批量不是银弹：
- 逻辑强依赖上一行结果时（比如滚动累加、状态机流转），硬套会破坏语义——这种场景老实用
FOR rec IN (SELECT ) LOOP，再配合MOD(i, 100) = 0做中间提交 - 数据量极小（
- 需要根据某条记录内容动态决定是否继续遍历（如查到特定值就
EXIT），FOR循环里的EXIT WHEN更直接
真正难的不是写对语法，而是判断哪段逻辑该交给 SQL 引擎、哪段必须留在 PL/SQL 控制流里——边界常在数据依赖性和执行路径分支上，而不是行数多少。
