FORALL 是 Oracle PL/SQL 中真正降低 IO 的核心机制，通过批量 DML 将 N 次 IO 压缩为 1 次；需配合 LIMIT 的 BULK COLLECT、索引 WHERE 条件及 SAVE EXCEPTIONS 才能安全高效运行。
forall 是 oracle pl/sql 中真正能压低 io 次数的核心机制，不是“语法糖”，而是直接绕过逐行 sql 引擎调用的底层优化。单次 forall 执行等价于一次批量 dml 请求，io 次数从 n 次降为 1 次（不含日志写），这是最直接有效的 io 减少手段。
为什么 FORALL 能显著降低 IO？
Oracle 的 IO 瓶颈主要来自磁盘随机读写（如回滚段、undo、redo 日志刷盘）和缓冲区争用。FORALL 的作用不是“让 UPDATE 更快”，而是让 N 行更新的 redo/undo 生成、锁获取、一致性读判断全部在 PL/SQL 引擎内批量完成，再一次性交由 SQL 引擎执行——这大幅压缩了上下文切换与日志写入频次。
- 普通
FOR循环：每行触发一次 SQL 引擎调用 → 每行都写 redo、申请 row cache lock、检查 ITL slot → IO 和 latch 争用爆炸 -
FORALL：集合数据一次性传入 → redo 合并写入、ITL 批量预分配、锁在语句级统一获取 → 实测 redo size 可减少 60%~90% - 注意：
FORALL不自动提交，仍需显式COMMIT；未加SAVE EXCEPTIONS时任意一行失败即整个批次回滚
FORALL + BULK COLLECT 必须配 LIMIT 防内存溢出
不设限的 BULK COLLECT 会把整张表加载进 PGA，极易触发 ORA-04030（内存耗尽）。而 LIMIT 不仅是“分批”，更是控制 PGA 占用与事务粒度的关键开关。
- 典型安全值：1000～5000 行/批，具体取决于每行平均大小（如含 CLOB 则必须下调）
- 错误写法：
SELECT * BULK COLLECT INTO t FROM big_table—— 表超 10 万行基本必崩 - 正确结构：用游标 +
FETCH ... BULK COLLECT INTO ... LIMIT n循环取数，每次只 hold 一批数据 - 额外收益：小事务降低锁持有时间，减少阻塞其他会话的概率
UPDATE 场景下，WHERE 条件必须走索引，否则 FORALL 白忙
FORALL 只解决“发请求次数”，不解决“每条 UPDATE 查多少块”。如果 WHERE 条件没走索引，每行更新都会触发全表扫描或大量逻辑读，IO 总量反而可能比单条还高（因缓存失效更严重）。
- 确认执行计划：对
UPDATE语句单独运行EXPLAIN PLAN，确保WHERE字段有可用索引且被 CBO 选用 - 避免隐式转换：
WHERE id = '123'（id 是 NUMBER）会导致索引失效，必须写成WHERE id = 123 - 复合索引要注意字段顺序：若常用
WHERE dept_id = ? AND status = ?，索引应建为(dept_id, status)，而非反过来
SAVE EXCEPTIONS 不是可选项，而是生产环境强制项
大批量更新中，个别脏数据（如外键约束失败、唯一键冲突、NULL 插入非空列）几乎必然存在。SAVE EXCEPTIONS 让失败行被隔离记录，其余行继续生效，避免整批重跑——这才是真实业务场景下的容错底线。
- 启用后必须处理
SQL%BULK_EXCEPTIONS：循环遍历异常数组，记录SQL%BULK_EXCEPTIONS(i).ERROR_INDEX对应原集合下标 - 不要只打印错误码：
SQLERRM(-SQL%BULK_EXCEPTIONS(i).ERROR_CODE)才能拿到实际报错信息（如ORA-00001） - 注意：异常记录不包含原始数据值，需提前保存关键字段（如主键）用于事后定位
批量 IO 优化真正的复杂点不在语法，而在于对“事务边界”“内存水位”“索引有效性”三者的实时权衡。一个没走索引的 FORALL，比老老实实用循环还伤 IO。
