pl/sql批量查数据不能只用普通loop，因逐行fetch引发高频上下文切换和引擎通信，性能极差；应使用bulk collect配合显式集合类型一次性加载数据，再用forall批量dml提升效率。
pl/sql里批量查数据，为什么不能只用普通loop？
因为逐行 fetch 会触发大量上下文切换和sql引擎与pl/sql引擎之间的反复交互通信，i/o和cpu开销直线上升。尤其当表有千万级记录、且需全表扫描时，普通游标循环可能比批量处理慢5–10倍。
真正该用的是 BULK COLLECT 配合显式集合类型，把结果一次性“捞”进内存数组，再统一处理：
DECLARE
TYPE t_id_tab IS TABLE OF employees.employee_id%TYPE;
l_ids t_id_tab;
BEGIN
SELECT employee_id BULK COLLECT INTO l_ids
FROM employees
WHERE department_id = 100;
-- 后续直接遍历 l_ids，不碰SQL引擎
END;
-
BULK COLLECT默认不限制行数，大数据量下可能撑爆PGA内存，务必配合LIMIT - 集合类型必须显式声明（如
TABLE OF ...），不能直接用%ROWTYPE数组接收多列结果 - 若查询返回0行，集合长度为0，但不会报错——检查
l_ids.COUNT是安全习惯
FORALL更新/删除大批量数据，为什么不能写成FOR i IN 1..tab.COUNT LOOP？
因为 FOR 循环里每执行一次 UPDATE 就是一次独立的DML语句，Oracle要解析、执行、生成回滚段、刷redo——开销爆炸。而 FORALL 把整个集合“打包”成一条逻辑DML操作，底层复用执行计划，仅一次解析、一次日志批写。
典型高效写法：
FORALL i IN 1 .. l_ids.COUNT UPDATE employees SET salary = salary * 1.1 WHERE employee_id = l_ids(i);
-
FORALL不是循环，它不支持IF、CONTINUE等控制语句；逻辑分支得在BULK COLLECT前过滤好 - 绑定变量必须是集合（如
l_ids(i)），不能是标量或表达式（如l_ids(i)+1） - 出错时默认整个
FORALL回滚，加SAVE EXCEPTIONS可捕获具体哪几条失败，但会略微降低性能
BULK COLLECT + FORALL组合使用，哪些边界情况最容易崩？
最常踩的坑不是语法错，而是内存和事务设计失当：
- 没设
LIMIT：全表BULK COLLECT百万行，直接触发ORA-04030（内存耗尽）；建议初值设1000～10000，按实际PGA调整 - 集合未清空就重复赋值：
l_ids := t_id_tab();或用l_ids.DELETE，否则旧数据残留导致逻辑错误 - 忘记检查
SQL%BULK_ROWCOUNT：比如FORALL更新时部分记录不满足WHERE条件，SQL%BULK_ROWCOUNT(i)返回0，但不会报错 - 事务太大：单次提交百万行，锁表时间长、undo膨胀、主从延迟飙升；应分批次
COMMIT，但注意避免在循环中频繁提交引发一致性读问题
替代方案对比：什么时候该放弃BULK COLLECT + FORALL？
当数据流转不局限于单个数据库实例，或需要强流控、容错重试时，这套PL/SQL机制反而成了瓶颈：
- 跨库同步、ETL场景：用
DBMS_PARALLEL_EXECUTE分块+并行，或迁移到外部工具（如GoldenGate、Data Pump） - 实时性要求高、数据持续写入：纯SQL的
MERGE或物化视图日志更轻量，避免长时间持有游标 - 需要逐行定制逻辑（如调用Web API、复杂校验）：硬上
BULK COLLECT反而增加内存拷贝开销，不如用游标+分页OFFSET/FETCH控制节奏
真正高效的批量处理，从来不是堆砌语法，而是清楚知道哪部分该交给SQL引擎做，哪部分必须拉到PL/SQL层——以及，哪部分根本不该放在这儿做。
