bulk collect 和 forall 是万行级批量处理的必备核心，不用则因上下文切换导致性能骤降；forall 执行前须初始化集合、校验 count、慎用 save exceptions；limit 推荐 500–5000 依场景调整；关联数组更适稀疏数据，嵌套表易引发执行计划漂移。
BULK COLLECT 和 FORALL 是实际能跑起来的批量处理核心，不是“可选优化项”——不用它们，万行级更新基本就卡在上下文切换上。
为什么直接用 FOR 循环 UPDATE 就慢？
每次 UPDATE 都触发一次 PL/SQL → SQL 引擎切换，10,000 行 = 10,000 次切换 + 解析 + 执行开销。实测中，纯循环比 FORALL 慢 5–20 倍，取决于 DML 复杂度和索引情况。
常见错误现象：ORA-04030（PGA 内存耗尽）或执行时间随数据量非线性暴涨，往往就是没切到批量模式。
- 别在循环里写
SELECT ... INTO+UPDATE，哪怕加了WHERE rownum = 1 -
FOR emp IN (SELECT ...)看似简洁，本质仍是单行驱动，不解决根本问题 - 如果必须逐行逻辑（比如每条记录要调用不同函数），先用
BULK COLLECT拉到内存，再用 PL/SQL 处理，最后统一FORALL提交
BULK COLLECT 的 LIMIT 怎么设才不翻车？
LIMIT 不是越大越好。设成 10000 看似吞吐高，但可能触发 Oracle 19c 的隐式分片（自动拆成多个子批），每个子批都要单独硬解析——尤其当你的 SELECT 含子查询或绑定变量时，解析开销会吃掉收益。
真实建议值取决于：集合元素大小、PGA 限制、SQL 复杂度。
- 常规场景（字段少、无大对象）：
LIMIT 5000是较稳起点 - 含
CLOB或长字符串字段：降到1000甚至500，避免 PGA spike - 查出来的集合后续要
FORALL更新同一张表：确保LIMIT与目标表的缓冲区命中率匹配，过大反而增加 buffer busy waits - 永远检查
V$SQL_PLAN中是否出现NESTED LOOPS回退——这说明优化器误判了集合大小，根源常是缺失直方图
FORALL 执行前必须做三件事
FORALL 不是“把数组丢进去就完事”。它对集合状态极其敏感，错一步就 ORA-06531 或静默跳过数据。
- 确认集合已初始化：
my_tab := my_tab_type();—— 即使空集合也要显式构造，否则my_tab.COUNT返回NULL而非0 - 别直接用
FORALL i IN 1..my_tab.COUNT：若集合来自BULK COLLECT且源 SQL 返回空结果，my_tab是NULL，立刻报错；改用IF my_tab.COUNT > 0 THEN FORALL... - 慎用
SAVE EXCEPTIONS：它不降低开销，只是延迟报错。19c 中仍需为每条失败语句维护独立错误上下文，内存占用翻倍；真要定位失败项，优先用INDICES OF+ 预校验（如SELECT COUNT(*) FROM DUAL WHERE my_tab(i).status IN ('A','P')）
关联数组 vs 嵌套表：选错类型会拖慢 30%+
三种集合类型行为差异极大，不能只看“都能存数据”：
-
INDEX BY PLS_INTEGER（关联数组）：唯一支持稀疏索引，INDICES OF可跳过空槽位，适合非连续 ID 或动态过滤后重排场景 - 嵌套表（
TABLE OF ...）：可持久化到表中，但FORALL时若用INDICES OF处理稀疏数据，19c 可能意外转成UNION ALL扫描多次，尤其碰上函数索引时 - VARRAY：长度固定，
BULK COLLECT不能直接 INTO VARRAY（会报ORA-06532），仅适合已知上限的缓存类场景 - 性能关键点：关联数组的
EXTEND是 O(1)，嵌套表的EXTEND在大数据量下有摊销成本；频繁DELETE后再FORALL，关联数组更稳
NULL、LIMIT 设得太大触发隐式分片、或者用嵌套表却忘了它在稀疏场景下执行计划会漂移。这些坑在 19c 里依然存在，且错误信息不直接指向根因。
