FORALL本身不提交，必须显式COMMIT；它仅批量执行DML，事务控制由用户决定，未提交则锁不释放、数据不可见、UNDO持续增长。
FORALL 本身不提交，必须显式 COMMIT
很多人误以为 FORALL 执行完就自动提交了，其实它只负责把数组里所有元素一次性发给 SQL 引擎执行 DML，事务控制完全交由你决定。不写 COMMIT，整个批量操作就在一个事务里悬着——锁没释放、UNDO 持续增长、别人查不到新数据。
常见错误现象：程序跑完没报错，但目标表查不到数据；或者并发时被长时间阻塞，v$session 显示 enq: TX - row lock contention。
- 每次
FORALL后都加COMMIT，适合在线业务（如定时同步），避免大事务拖垮系统 - 若需原子性（全部成功或全部回滚），就把所有
FORALL包在同一个事务里，最后统一COMMIT或ROLLBACK - 别在循环内无条件
COMMIT—— 万一中间出错，已提交的部分无法撤回
FORALL 必须搭配简单类型数组，不能直接用 %ROWTYPE 集合
FORALL 的 VALUES 子句不支持 %ROWTYPE 集合直接绑定，否则会报 PLS-00436 错误。这不是语法限制，而是 Oracle 内部绑定机制要求字段级对齐。
比如你从 source_table 查出数据想插进 target_table，下面这样写会失败：
TYPE t_tab IS TABLE OF source_table%ROWTYPE; l_data t_tab; ... FORALL i IN 1..l_data.COUNT INSERT INTO target_table VALUES l_data(i); -- ❌ PLS-00436
正确做法是拆成字段级数组：
TYPE id_tab IS TABLE OF source_table.id%TYPE; TYPE name_tab IS TABLE OF source_table.name%TYPE; l_ids id_tab; l_names name_tab; ... FORALL i IN 1..l_ids.COUNT INSERT INTO target_table (id, name) VALUES (l_ids(i), l_names(i)); -- ✅
- 字段多时别硬拆，改用
INSERT /*+append*/ SELECT ... FROM TABLE(CAST(? AS ...))动态拼接 - 如果只是单表复制且结构一致，优先走
INSERT INTO ... SELECT ...，比FORALL更轻量
BULK COLLECT + FORALL 要分批，LIMIT 值不是越大越好
不分批的 BULK COLLECT INTO 容易触发 ORA-04030（PGA 内存耗尽）；但 LIMIT 设成 100 或 50000 都可能翻车：前者循环次数太多，抵消批量收益；后者在 Oracle 19c+ 可能触发隐式分片，导致多次硬解析。
真实推荐值取决于数据特征：
- 常规场景（字段少、无 LOB）：
LIMIT 5000是较稳起点 - 含
CLOB或长VARCHAR2：LIMIT 500起步，观察 PGA 使用率 - 后续要
FORALL UPDATE同一张表：LIMIT 过大会加剧buffer busy waits，建议先压测v$segment_statistics
另外，EXIT WHEN c%NOTFOUND 不可靠——如果最后一轮刚好取满 LIMIT，c%NOTFOUND 仍为 FALSE，必须配合 l_data.COUNT = 0 判断。
FORALL 执行前必须检查集合状态，否则静默跳过或直接报错
FORALL i IN 1..l_data.COUNT 看似稳妥，但如果 l_data 是 NULL（比如 BULK COLLECT 的源查询没返回任何行），l_data.COUNT 就是 NULL，立刻抛 ORA-06531。
安全写法是三步走：
- 声明后立即初始化：
l_data := t_tab(); - FETCH 后判空：
IF l_data.COUNT > 0 THEN FORALL ... - 慎用
SAVE EXCEPTIONS：它不省资源，只是延迟报错；19c 中每条失败语句仍占独立错误上下文，内存开销翻倍
真正需要定位哪几条失败时，优先用 INDICES OF + 预校验逻辑（例如先查 COUNT(*) 过滤掉非法状态），而不是依赖 SQL%BULK_EXCEPTIONS 回溯。
最常被忽略的一点：FORALL 的性能收益完全依赖于“一次绑定、批量执行”这个前提——只要中间穿插了 PL/SQL 计算、函数调用或条件分支，上下文切换就又回来了。
