PL/SQL集合大量填充会耗尽PGA内存，因其完全驻留PGA且不共享、不换出；必须用LIMIT控制BULK COLLECT规模，预分配优于反复EXTEND，处理完及时DELETE或置NULL释放内存。
PL/SQL 集合（如 VARCHAR2 表、NUMBER 表、嵌套表）在存储过程中大量填充时，确实会直接吃掉 PGA 内存，尤其在循环中无节制 EXTEND 或用 BULK COLLECT 一次性拉取数万行，很容易触发 ORA-04030（进程内存耗尽）或拖慢整个会话。
这不是“集合不能用”，而是没控制好生命周期和规模。
为什么集合会撑爆 PGA？
pl/sql 集合变量完全驻留在 pga 中，不共享、不换出。哪怕只是 declare type t_list is table of varchar2(4000); l_data t_list;，一旦执行 select ... bulk collect into l_data 拉入 10 万行，每行平均占 2kb，光数据就吃掉 ~200mb pga —— 这还没算描述符、哈希桶、扩展开销。
用 BULK COLLECT 时必须配 LIMIT
直接 BULK COLLECT INTO 全表，等于把结果集全拷进 PGA。真实场景里几乎从不需要一次全拿。
- 永远显式加
LIMIT：比如FETCH c_cur BULK COLLECT INTO l_ids LIMIT 1000; -
LIMIT值不是越大越好：500–5000 是较安全区间；超过 10000 就得测 PGA 消耗 - 配合
EXIT WHEN c_cur%NOTFOUND;，别依赖COUNT判断循环结束 - 每次循环后，集合变量自动清空（只要没
EXTEND手动扩容），不用DELETE，但建议显式l_ids.DELETE;更可读
别在循环里反复 EXTEND + l(i) := ...
这是最隐蔽的内存泄漏写法：每次 EXTEND 都让集合底层数组重新分配更大连续内存块，旧块不会立即释放，PGA 碎片化加剧。
- 优先预分配：如果知道大概数量，用
l_data := t_list(); l_data.EXTEND(5000); - 更推荐用
FORALL+ 已知大小集合，避免运行时动态伸缩 - 真要逐条追加，改用
l_data(l_data.COUNT + 1) := val;（隐式 EXTEND），比显式调用稍轻量，但仍不如预分配 - 绝对不要写
FOR i IN 1..100000 LOOP l_data.EXTEND; l_data(l_data.COUNT) := ... END LOOP;
大集合处理完立刻 l_data.DELETE 或置为 NULL
集合变量生命周期只到块结束，但 PGA 不会实时归还——尤其当它曾膨胀过。主动清理能加快内存回收，也避免后续误用旧数据。
-
l_data.DELETE;清空内容，保留结构（仍可再赋值） -
l_data := NULL;彻底释放内存，下次需重新初始化 - 放在关键逻辑段末尾，比如批量处理完、事务提交后
- 注意：
l_data.DELETE对ASSOCIATIVE ARRAY（索引表）无效，它用l_data.DELETE是清空全部，但对稀疏结构更推荐l_data := t_type();
LIMIT 缺失，以及把集合当成“无限容器”来用的习惯——PGA 不是堆内存，没 GC，撑满了就只能报错或卡死。 
