选错PL/SQL集合类型会严重拖慢执行速度：VARRAY存日志、INDEX BY TABLE做批量INSERT缓存均易引发性能反效果；应按场景选用——读多写少用INDEX BY PLS_INTEGER+FORALL，需持久化或SQL层操作才用NESTED TABLE。
PL/SQL中集合类型选错会拖慢执行速度
用 VARRAY 存 10 万条日志、用 INDEX BY TABLE（即关联数组）做批量 INSERT 的中间缓存，都可能引发性能反效果。Oracle 对三类集合的内存管理、扩展机制和访问路径完全不同：嵌套表（NESTED TABLE）支持持久化但初始化开销大；VARRAY 长度固定、拷贝成本高；而 INDEX BY PLS_INTEGER 是纯内存结构、无长度限制、索引随机访问快——但不能直接 INSERT BULK。
常见错误现象包括：
- 循环中反复
EXTEND一个VARRAY，触发多次内存重分配 - 用
NESTED TABLE存临时计算结果，却没声明NOT NULL或未预设INITIAL大小，导致隐式扩容和碎片 - 误以为
INDEX BY VARCHAR2比PLS_INTEGER更灵活，实则哈希查找慢且内存占用翻倍
批量操作优先用 INDEX BY PLS_INTEGER + BULK COLLECT / FORALL
这是 PL/SQL 中最常被验证有效的组合。它绕过单行 SQL 执行开销，把数据暂存在高速内存结构中，再一次性交由 SQL 引擎处理。
使用场景明确：读多写少、中间聚合、条件过滤后暂存、需按序或随机访问索引的场景。
关键点：
-
INDEX BY PLS_INTEGER不需要EXTEND，直接赋值即可：my_tab(1) := 'a'; my_tab(my_tab.COUNT + 1) := 'b'; -
BULK COLLECT INTO必须配合INDEX BY或嵌套表；若用嵌套表，记得先:= my_nested_type()初始化空集合 -
FORALL i IN INDICES OF my_tab比FORALL i IN 1 .. my_tab.COUNT更安全——自动跳过稀疏索引（比如中间DELETE过的元素） - 避免在
FORALL中混用 DML 和函数调用；所有计算应在BULK COLLECT后、FORALL前完成
NESTED TABLE 只在需要持久化或传参给 SQL 层时才用
它唯一不可替代的用途是：作为表列类型（CREATE TABLE t (id NUMBER, tags NESTED TABLE)），或作为 PIPELINED 函数返回值，或用于 TABLE() 运算符展开成行集。除此之外，在纯 PL/SQL 过程里用它，基本等于主动引入 I/O 和解析开销。
容易踩的坑：
- 声明为
TYPE t_nt IS TABLE OF VARCHAR2(100); v_nt t_nt;后，不初始化就直接v_nt.EXTEND→ 报ORA-06531: Reference to uninitialized collection - 用
v_nt := t_nt('a','b')初始化后，再EXTEND，实际触发了两次内存分配（构造 + 扩容） - 在
FORALL中绑定NESTED TABLE变量，Oracle 会将其转为临时表并走磁盘，失去批量优势
别忽略 LIMIT 和内存水位控制
哪怕用了 INDEX BY，一次 BULK COLLECT 拉 500 万行仍可能导致 PGA 爆炸、触发 swap。Oracle 不会自动分批，全靠你控制。
正确做法是显式加 LIMIT，并用循环收拢：
DECLARE
TYPE t_list IS TABLE OF employees%ROWTYPE INDEX BY PLS_INTEGER;
v_data t_list;
CURSOR c_emp IS SELECT * FROM employees;
BEGIN
OPEN c_emp;
LOOP
FETCH c_emp BULK COLLECT INTO v_data LIMIT 1000;
EXIT WHEN v_data.COUNT = 0;
FORALL i IN INDICES OF v_data
INSERT INTO emp_log VALUES v_data(i);
COMMIT;
END LOOP;
CLOSE c_emp;
END;注意：LIMIT 值不是越大越好。测试表明，在多数 OLTP 场景下，500–2000 是较优区间；超过 5000 后，PGA 增长非线性，而吞吐提升趋缓。真正卡住性能的，往往不是集合类型本身，而是没做这层分片控制。
