bulk collect不能用标量变量接收，因其设计目标是一次搬运多行，要求into后变量必须为集合类型；若用标量则报pls-00497错误，因sql引擎返回的是多值集合，pl/sql必须用能容纳“一组”的容器接收。
为什么BULK COLLECT不能直接用标量变量接收
因为 BULK COLLECT 的设计目标是「一次搬运多行」，它要求所有 INTO 后的变量必须是集合类型。如果你写 SELECT col BULK COLLECT INTO v_val FROM t，而 v_val 是 NUMBER 这样的标量，Oracle 会立刻报 PLS-00497: cannot mix between single row and multi-row (BULK) operations。这不是语法写错，而是类型契约强制——SQL 引擎传来的是一组值，PL/SQL 必须用能装下“一组”的容器去接。
三种常用 INTO 场景怎么声明集合变量
关键不在怎么写 BULK COLLECT，而在前置的集合定义是否匹配使用方式：
-
查单列、纯数值/字符串场景：用
TABLE OF VARCHAR2(100) INDEX BY PLS_INTEGER（关联数组），支持稀疏索引、无需预分配大小，适合后续做键值查找 -
查多列、需保持字段结构：先定义
RECORD类型，再基于它定义TABLE OF record_type（嵌套表），这样每条记录字段可直接通过tab(i).col1访问 -
查整行、表结构可能变化：用
%ROWTYPE声明嵌套表，如TYPE emp_tab IS TABLE OF employees%ROWTYPE，但注意这会把所有字段都拉进来，内存开销大
游标分批 FETCH 时 LIMIT 不是可选项
大数据集不用 LIMIT 就等于裸奔。不加限制的 FETCH cur BULK COLLECT INTO tab 可能一次性加载百万行，触发 ORA-04030（PGA 耗尽）或让 PGA 占用飙升拖慢整个实例。实际写法必须带 LIMIT，且值要权衡：
- 太小（如
LIMIT 10）：上下文切换没减多少，还增加循环次数 - 太大（如
LIMIT 100000）：单次内存压力大，GC 频繁，可能被 ORA-04030 拦截 - 经验值：500–5000 行之间较稳，具体看单行平均字节数和 PGA 限制
示例中常见错误是把 LIMIT 写在 OPEN 后、FETCH 前，正确位置只在 FETCH ... BULK COLLECT INTO ... LIMIT n 这一行里。
FORALL 批量 DML 时集合长度必须一致
当你用 FORALL i IN l_ids.FIRST .. l_ids.LAST INSERT INTO t VALUES (l_ids(i), l_names(i))，如果 l_ids 和 l_names 长度不同、或某次 BULK COLLECT 后集合为空，FORALL 会直接报 ORA-22160 或下标越界。必须确保：
- 所有参与
FORALL的集合，在每次BULK COLLECT后都用.COUNT校验长度一致 - 空集合要显式跳过
FORALL块，否则i IN NULL..NULL会出错 - 不要混用
FIRST..LAST和1..COUNT：前者对稀疏关联数组可能跳过中间空位，后者更安全
真正容易被忽略的是集合生命周期管理——每次循环前没清空旧数据，或没重置索引，会导致上一轮残留数据干扰本轮逻辑。别指望 Oracle 自动帮你清理。
