FORALL不是for循环加速版，仅在集合COUNT一致、批量大小500~2000、索引控制得当且无表达式/条件逻辑时才高效；否则易报ORA-06512、ORA-01408，甚至比单条插入更慢。
FORALL 不是“for 循环加速版”，它只在集合对齐、批量大小合理、索引控制得当的前提下才比单条 INSERT 快；用错反而更慢，甚至报 ORA-06512 或 ORA-01408。
FORALL 绑定多个集合时 COUNT 必须完全一致
常见错误现象：执行时报 ORA-06512，或插入后部分字段为 NULL、唯一约束冲突（ORA-00001）、索引键重复（ORA-01408）。根本原因不是数据问题，而是集合长度不一致。
-
a_arr.COUNT≠b_arr.COUNT→ FORALL 按下标硬绑定，b_arr(5)若为空或未赋值，Oracle 仍会传NULL或触发约束校验 - 填充方式混用：一个集合用
EXTEND动态追加，另一个用固定下标（如c_arr(3) := 'x'）→ 稀疏数组，COUNT 可能相同但有效元素错位 - 调试必加：
DBMS_OUTPUT.PUT_LINE('a:'||a_arr.COUNT||' b:'||b_arr.COUNT);，别等报错再查
BULK COLLECT LIMIT 值设多少才不翻车
很多人以为 LIMIT 越大越好，结果 PGA 暴涨、临时段写入频繁、GC 压力陡增，实测吞吐反而下降。这不是 PL/SQL 慢，是内存管理失控。
- OLTP 场景推荐
LIMIT 500~2000：这是 Oracle 12c+ 隐式分片优化的“甜点区” - 超
LIMIT 5000易触发问题：目标表有 3+ 索引或触发器时，FORALL 优势快速归零；PGA 不足直接抛ORA-22813 - 不要盲目调大
pga_aggregate_target：先压测 LIMIT=1000 和 LIMIT=2000 的实际耗时与内存占用，再决定是否扩容
FORALL 不支持表达式、函数或条件逻辑
错误写法会直接编译失败或运行时报 ORA-06550。FORALL 只接受静态 SQL + 集合元素直引，所有计算必须前置完成。
- 禁止在 FORALL 内写：
UPPER(name_arr(i))、CASE WHEN ...、SYSDATE + 1、子查询、DBLink 表引用 - 正确做法：用普通循环预处理集合，例如
name_upper(i) := UPPER(name_arr(i));，再进 FORALL - 慎用
INDICES OF：它跳过稀疏空位，但其他集合不会自动对齐——若没做映射，ERROR_INDEX查出来的就是错的记录
索引、提交和约束才是真正拖慢批量插入的元凶
很多人只盯着 FORALL，却忽略物理层开销。即使 FORALL 执行成功，插入速度仍可能卡在索引维护、约束检查或自动提交上。
- INSERT 目标表若有唯一索引，FORALL 仍逐条检查冲突——批量 ≠ 跳过约束校验
- 非关键字段上的索引建议临时禁用：
ALTER INDEX idx_name UNUSABLE;，插入完再重建 - 务必关闭 AUTOCOMMIT：否则每次 FORALL 后隐式提交，等于退化成单条插入；显式
COMMIT放在 LOOP 外或按批次控制 - 如果只是从源表搬数据，优先考虑
INSERT /*+ APPEND */ INTO ... SELECT，它绕过 buffer cache，比 FORALL + BULK COLLECT 更快
最容易被忽略的一点：FORALL 的错误定位成本远高于普通循环。SAVE EXCEPTIONS 下的 ERROR_INDEX 是内部序号，不是你原始集合下标——没做映射就去查源数组，90% 会取错记录。
