根本原因是bulk collect默认不限行数，会将全表数据硬塞入pga，叠加pga内存刚性限制与集合类型隐式膨胀，导致ora-04030崩溃；必须显式写limit于fetch末尾，配合嵌套表类型、count=0退出及sql层索引优化。
BULK COLLECT 占用大量内存，根本原因不是它“太贪”，而是**默认不限行数 + PGA 内存模型刚性 + 集合类型隐式膨胀**三者叠加的结果。不加 LIMIT，它真会把整张表塞进当前会话的 PGA —— 不是慢，是直接 ORA-04030 崩溃。
不写 LIMIT 就等于全量加载到 PGA
Oracle 的 BULK COLLECT 默认行为是“取完为止”。它不关心你表有多大、字段多宽、有没有 LOB，只要游标能返回，它就往 PGA 里硬塞。
- 查一张 30 万行、含
CLOB字段的表，实际 PGA 占用可能超 1.2GB（CLOB指针 + 缓冲区开销） -
PGA_AGGREGATE_TARGET是会话级硬上限，不是“建议值”；RAC 环境下多个会话共用 PGA 区，一个游标吃满，其他会话直接卡死 - 别信“我这台库内存有 128G”——PGA 是 per-session 的，跟 OS 总内存无关
LIMIT 必须放在 FETCH 末尾，不能塞在 SELECT 或 OPEN 里
LIMIT 是 FETCH 的子句，语法位置错，Oracle 直接忽略，等效于没写。
- ✅ 正确：
FETCH c_emp BULK COLLECT INTO l_tab LIMIT 1000 - ❌ 错误：
OPEN c_emp LIMIT 1000（编译报错） - ❌ 错误：
SELECT ... FROM t WHERE ... LIMIT 1000（Oracle 不支持该语法，SQL 层无作用） - 含
CLOB/BLOB时，LIMIT必须 ≤ 100；纯数值/字符串字段可设 500–1000，但别盲目拉到 5000
集合类型选错，内存浪费翻倍且 FORALL 失效
声明集合类型不是“能跑就行”，不同类型对内存布局和访问路径影响极大。
- 用
VARRAY：长度固定，EXTEND超限直接ORA-06532；且无法被FORALL安全遍历 - 用
INDEX BY VARCHAR2：下标稀疏，FORALL i IN 1..v_tab.COUNT会跳过空位，漏数据 - ✅ 推荐：
TYPE t_tab IS TABLE OF your_table%ROWTYPE（嵌套表），最通用、最稳、FORALL可直接用 - 如果只更新
employee_id和status，别用%ROWTYPE，改用TYPE t_ids IS TABLE OF employees.employee_id%TYPE+t_status两个独立集合，省掉整行结构体开销
退出条件写 %NOTFOUND 是典型陷阱
%NOTFOUND 在 BULK COLLECT 后不可靠：最后一批只取到 1 行时，%NOTFOUND 仍是 FALSE；必须再 FETCH 一次才变 TRUE —— 这次额外 fetch 会触发 NO_DATA_FOUND 异常或空集合，徒增 IO 和风险。
- ✅ 正确退出：
EXIT WHEN l_tab.COUNT = 0，每次FETCH后立刻判断 - 每次循环开始前必须清空集合：
l_tab.DELETE（不是l_tab := t_tab()，后者易因类型细微不匹配报PLS-00382） - 别依赖
l_tab.COUNT做FORALL前判断——19c 中若BULK COLLECT结果为空，l_tab是NULL而非空集合，直接FORALL报ORA-06531
BULK COLLECT 本身，而是它背后那条没走索引、没裁剪列、没加提示的 SQL。再快的批量，也救不了全表扫描 + SELECT * 的组合。调优时盯着 v$process.pga_used_mem 看趋势，比光看代码更准。
