循环内SELECT INTO是性能雷区，因每次执行都触发独立SQL解析、执行计划生成、数据块读取和上下文切换，导致软解析、buffer gets和网络开销剧增；应改用BULK COLLECT批量查询+FORALL或游标FOR循环处理。
为什么循环里写 SELECT INTO 是性能雷区
因为每次执行都会触发一次独立的 SQL 解析、执行计划生成、数据块读取和上下文切换。在 PL/SQL 循环中反复调用它，相当于把本可批量完成的事拆成几百上千次“小快递”，网络往返（如果是远程调用）、软解析开销、buffer gets 都会指数级上升。你看到的不是“慢”，而是“不该这么干”。
SELECT INTO 能否直接改成集合批量查询
不能直接替代，但可以绕开。关键在于：把循环内单行查，变成循环外一次性查出全部结果，再用集合（TYPE ... IS TABLE OF ...）承载，最后用 FORALL 或游标 FOR 循环处理。
-
SELECT INTO本身只支持单行，强行塞多行会报ORA-01422 - 改用
BULK COLLECT INTO可一次取多行到集合变量中，这是真正批量化的起点 - 后续若需对每行做 DML，优先用
FORALL INSERT/UPDATE/DELETE，而非循环里嵌INSERT - 如果只是读+简单计算，用显式游标
FOR rec IN (SELECT ...)最简洁，Oracle 自动管理打开/关闭/fetch
常见错误：用隐式游标 SELECT INTO 模拟循环逻辑
比如有人写：
FOR i IN 1..100 LOOP SELECT name INTO v_name FROM emp WHERE id = i; -- 处理 v_name END LOOP;
这实际是 100 次独立查询。更糟的是，如果某 id 不存在，立刻抛 ORA-01403 中断整个循环——而你本意可能只是跳过该记录。
- 正确做法是先
SELECT id, name BULK COLLECT INTO l_ids, l_names FROM emp WHERE id BETWEEN 1 AND 100 - 然后用
FOR j IN 1..l_ids.COUNT LOOP遍历集合，天然规避空值中断问题 - 若必须按顺序处理且允许缺失，可在
BULK COLLECT后加WHERE ROWNUM 控制上限，避免全表扫描
什么情况下还不得不保留循环内 SELECT INTO
极少，但存在：比如每次查询条件强依赖上一轮的计算结果（非简单 ID 递增），或涉及动态 SQL 且无法提前预知所有键值。这时必须接受性能代价，并做三件事：
- 确保被查字段有高效索引，避免
FULL TABLE SCAN - 用
EXCEPTION显式捕获NO_DATA_FOUND，别让它冒泡 - 加上
/*+ RESULT_CACHE */提示（仅当数据变化不频繁时），让 Oracle 缓存结果
真正难处理的不是语法，而是没想清楚“这个查询是否真的必须在循环里做”。多数时候，把条件拉出来、聚合、批量取，才是正解。
