FORALL + BULK COLLECT 是Oracle批量处理的高效路径，因它减少PL/SQL与SQL引擎间上下文切换；禁用%ROWTYPE集合直连VALUES插入，须拆为同构简单类型集合或改用INSERT SELECT，并严格匹配LIMIT与COUNT、及时清空集合、加索引防全扫、显式COMMIT。
直接上 FORALL + BULK COLLECT 是唯一靠谱的批量插入路径；逐行 INSERT 或隐式游标循环在万级以上数据量下必然卡死、锁表、OOM。
为什么不能用 SELECT ... BULK COLLECT INTO 含 %ROWTYPE 的集合
Oracle 不允许把查询结果直接 BULK COLLECT INTO 到 %ROWTYPE 类型的嵌套表里再喂给 FORALL INSERT VALUES。常见报错是 PLS-00487: Invalid reference to variable or pseudo-column 'V_TABLE' 或编译不通过。
-
%ROWTYPE集合（如TYPE t_tab IS TABLE OF source_table%ROWTYPE）只能用于FORALL ... INSERT ... SELECT，不能用于VALUES v_table(i) - 若坚持用
VALUES，必须拆成多个同构简单类型集合：比如分别声明t_id_tab、t_name_tab，再BULK COLLECT INTO t_id_tab, t_name_tab - 更省事的做法是改用
FORALL ... INSERT SELECT，让 Oracle 在 SQL 层完成字段映射，避免 PL/SQL 层手动拆包
FORALL 插入时 LIMIT 和数组长度必须严格匹配
FORALL i IN 1..l_ids.COUNT INSERT ... WHERE id = l_ids(i) 这类写法依赖 l_ids.COUNT 实时反映本次 FETCH 的真实行数。如果硬写成 1..10000，最后一批不足 1 万就会触发 ORA-06533: Subscript beyond count。
- 每次
FETCH ... BULK COLLECT INTO ... LIMIT 10000后，立刻检查l_ids.COUNT = 0再EXIT WHEN - 不要复用未清空的集合变量——前一批残留数据会导致重复插入或逻辑错乱，建议每次 FETCH 前加
l_ids.DELETE或重新初始化l_ids := t_id_tab() -
LIMIT值不是越大越好：10000 是平衡点；设 50000 容易触发ORA-04030（PGA 内存耗尽），设 100 则上下文切换开销反超收益
INSERT SELECT 比 VALUES 更稳，但要注意 WHERE 条件和索引
用 FORALL i IN 1..l_ids.COUNT INSERT INTO target SELECT ... FROM source WHERE id = l_ids(i) 能绕过 %ROWTYPE 限制，也更易调试。但它对执行计划敏感，容易全表扫描。
- 确保
source表上id有索引（主键或唯一约束最佳），否则每批 1 万次单值查找会退化成 1 万次全表扫描 - 如果目标表有唯一约束或触发器，
FORALL仍会批量校验/触发，失败时整批回滚；加SAVE EXCEPTIONS可定位具体哪几条失败，但会略降性能 - 别忘了显式
COMMIT—— 必须放在END LOOP前，且不能靠自治事务兜底；否则事务堆积导致锁升级、undo 段爆满
最易被忽略的是集合生命周期管理：FETCH 前不清空、COMMIT 前不检查 SQL%BULK_ROWCOUNT（比如部分 id 在源表已不存在，INSERT SELECT 实际插入 0 行却不报错），这些细节不处理，上线后就是静默数据丢失。
