如何使用Oracle FORALL提升批量更新性能？

FORALL本质是Oracle批量DML的底层SQL引擎优化，非加速版for循环；必须确保所有绑定集合COUNT完全一致，否则触发ORA-06512；批量大小宜控在500～2000，超限易致PGA暴涨、游标失效；不支持表达式、函数或条件分支，错误处理中ERROR_INDEX需映射还原。

FORALL 不是“加速版 for 循环”，它本质是 Oracle 对批量 DML 的底层 SQL 引擎优化；用错集合对齐、盲目调大批量或混用表达式，性能反而比逐行还差。

FORALL 更新必须保证所有绑定集合 COUNT 完全一致

Oracle 不校验逻辑对齐，只按索引位置硬绑定。一旦 id_arr.COUNT ≠ name_arr.COUNT，立刻报 ORA-06512。常见错误包括：

1. 一个集合用 EXTEND 动态追加，另一个用固定下标（如 name_arr(5) := 'xxx'）导致稀疏空位
2. FETCH BULK COLLECT INTO 时 LIMIT 超出剩余行数，但后续未检查 l_ids.COUNT 就直接进 FORALL
3. 用了 INDICES OF idx_list，但其他集合没做对应映射，造成错位

实操建议：每次 FETCH 后立即加 DBMS_OUTPUT.PUT_LINE('ids:'||l_ids.COUNT||' names:'||l_names.COUNT)；填充集合统一用同一循环，例如：FOR i IN 1..n LOOP id_arr.EXTEND; id_arr(i):=...; name_arr.EXTEND; name_arr(i):=...; END LOOP;

批量大小控制在 500～2000 是性能甜点区

设太大（如 LIMIT 10000）会导致 PGA 内存暴涨、临时段写入频繁、游标失效，尤其当目标表有 3+ 索引或触发器时，优势迅速归零。19c 隐式分片优化依赖可控的单次绑定量。

1. OLTP 场景推荐 LIMIT 500～2000，实测吞吐最稳
2. 超 5000 易触发临时段写入或游标失效
3. 务必关闭 AUTOCOMMIT，否则每次 FORALL 后自动提交，退化成单条执行

SAVE EXCEPTIONS 下 ERROR_INDEX 不是源数组下标

启用 SAVE EXCEPTIONS 后，SQL%BULK_EXCEPTIONS(i).ERROR_INDEX 返回的是 FORALL 内部执行序号（从 1 开始），不是你原始集合的物理下标。直接拿它去查 id_arr 会取错记录。

1. 若没用 INDICES OF：正确写法是 failed_id := id_arr(SQL%BULK_EXCEPTIONS(i).ERROR_INDEX)
2. 若用了 INDICES OF idx_list：需再映射一层 —— orig_idx := idx_list(SQL%BULK_EXCEPTIONS(i).ERROR_INDEX); failed_id := id_arr(orig_idx)
3. 取错误码必须用 SQLERRM(-SQL%BULK_EXCEPTIONS(i).ERROR_CODE)；单独调用 SQLERRM 只返回最后一条

FORALL 不支持表达式、函数或条件分支

FORALL 只接受静态 SQL，所有绑定变量必须是集合元素直引。下面都是非法写法：

1. FORALL i IN 1..arr.COUNT UPDATE t SET name = UPPER(arr2(i)) WHERE id = arr(i) → 报 ORA-06550
2. CASE WHEN ... THEN ...、子查询、@dblink 全部不支持

实操建议：预处理集合，例如先循环生成 name_upper(i) := UPPER(arr2(i))，再在 FORALL 中绑定 name_upper(i)。

最容易被忽略的是：FORALL 的性能收益高度依赖目标表结构与事务控制策略——索引越多、触发器越重，单次批量的优势衰减越快；而错误处理中对 ERROR_INDEX 的误用，往往让 SAVE EXCEPTIONS 变成“静默失败”的陷阱。