BULK COLLECT 必须配合 LIMIT 使用，否则会全量加载结果集至 PGA 导致内存溢出；正确写法是 FETCH 后跟 LIMIT，用集合 COUNT 判断循环退出，而非 %NOTFOUND。
直接结论：用 bulk collect 配合 limit 是处理大结果集最稳妥的游标优化手段，它能压低内存峰值、避免 pga 溢出，同时比纯逐行 fetch 快 5–20 倍——但前提是 limit 值不能拍脑袋定。
为什么不能只用 BULK COLLECT 不加 LIMIT
全量 BULK COLLECT INTO 会一次性把整个结果集加载进 PGA 内存。当查询返回几十万行时，容易触发 ORA-04030（内存耗尽）或拖慢整个实例。尤其在共享 PGA 的 RAC 环境下，一个游标就可能挤占其他会话资源。
常见错误现象：ORA-04030: out of process memory、PL/SQL 执行突然变慢、AWR 中 PGA memory freed 飙升。
实操建议：
-
LIMIT值建议设为 100–1000，具体看单行数据大小：若每行平均 2KB，LIMIT=500 就占约 1MB PGA；若含 CLOB，必须压到 100 以下 - 避免写成
SELECT * BULK COLLECT INTO ...，只选真正需要的列，减少内存和网络开销 - 集合类型必须显式声明为
INDEX BY PLS_INTEGER或使用TYPE ... IS TABLE OF ...，否则隐式转换可能引入额外开销
标准写法中 LIMIT 放哪、怎么判断结束
LIMIT 只能出现在 FETCH 语句末尾，不能放在 OPEN 或 SELECT 里。循环退出条件不是靠 %NOTFOUND，而是看每次 FETCH 实际取到的行数是否为 0。
典型结构：
DECLARE
TYPE emp_tab IS TABLE OF employees%ROWTYPE;
l_emps emp_tab;
CURSOR c_emp IS SELECT employee_id, last_name FROM employees WHERE department_id = 50;
BEGIN
OPEN c_emp;
LOOP
FETCH c_emp BULK COLLECT INTO l_emps LIMIT 500;
EXIT WHEN l_emps.COUNT = 0; -- 关键：用 COUNT 判断，不是 %NOTFOUND
-- 处理 l_emps 中的每一行
FOR i IN 1..l_emps.COUNT LOOP
DBMS_OUTPUT.PUT_LINE(l_emps(i).last_name);
END LOOP;
END LOOP;
CLOSE c_emp;
END;注意：%NOTFOUND 在 BULK COLLECT 后不可靠，因为即使最后一批只取到 1 行，%NOTFOUND 仍是 FALSE，直到再 FETCH 一次才变 TRUE——这会导致多一次空 fetch，浪费 IO。
和 FORALL 配合更新时的坑
用 BULK COLLECT + FORALL 替代游标循环更新，性能提升明显，但有三个硬约束：
- FORALL 的 DML 必须用集合下标（如
emp_ids(i)），不能混用WHERE CURRENT OF - 如果
FORALL UPDATE中某条失败（如违反唯一约束），默认整个批处理报错；需加SAVE EXCEPTIONS并配合SQL%BULK_EXCEPTIONS捕获，否则中断后无法知道哪几行失败 - 集合长度超过 10000 时，Oracle 可能自动拆分成多个子批，但不会通知你——建议主动控制
LIMIT≤ 5000，避免执行计划突变
示例中易错点：FORALL i IN l_emps.FIRST..l_emps.LAST 不能写成 FORALL i IN 1..l_emps.COUNT，因为集合可能稀疏（比如用了 DELETE 清过中间元素）。
替代方案对比：FOR 循环 vs BULK COLLECT + LIMIT
PL/SQL 的 FOR rec IN (SELECT ...) 写法看着简洁，但它底层仍是逐行 fetch，没有批量优势；且无法控制内存用量，不适合 >1 万行的场景。
而 BULK COLLECT + LIMIT 是唯一能兼顾可控内存、可预测性能、且适配复杂业务逻辑（比如每批做校验、调用外部函数）的方式。它的代价是代码略长，但换来的是稳定性和可观测性——比如你可以轻松加日志：DBMS_OUTPUT.PUT_LINE('Fetched ' || l_emps.COUNT || ' rows');。
真正容易被忽略的点：很多人把 LIMIT 当成“性能开关”，却忘了检查游标本身的 SQL 是否走索引。如果 SELECT 本身触发全表扫描，再怎么优化 fetch 方式也救不回响应时间。先看执行计划里的 ACCESS_PREDICATES，再调 LIMIT。
