双层FOR循环查表导致逻辑读爆炸，应改用SQL JOIN或BULK COLLECT+FORALL批量处理；高频小表查询宜缓存至INDEX BY数组；强依赖前序结果的场景仍需逐行处理。
别在pl/sql里写双层for循环查表，这是逻辑读爆炸的头号原因——每轮内层循环都触发一次独立sql执行，10万次循环≈30万+逻辑读，而改用集合操作后通常压到5000以内。
为什么嵌套循环会导致逻辑读飙升
不是SQL本身慢，而是调用方式把开销放大了：每次SELECT ... INTO都在走完整解析→执行→获取流程，哪怕数据块已在buffer cache，仍计入逻辑读。更糟的是，Oracle没法复用游标状态，软解析、一致性读判断、PGA分配全得重来。
- 典型症状：
V$SESSION_EVENT里latch: row cache objects或library cache lock等待突增 - 真实代价：单次循环至少2次用户态/内核态切换 + 1次软解析 + 1次buffer pin争用
- 别信“加索引就能救”——索引只减少内表扫描行数，但N×M次调用本身无法消除
用BULK COLLECT + FORALL替代双层FOR循环
核心是把多次单行访问合并为一次批量拉取，再在内存里做匹配或计算。重点不是语法替换，而是把控制权从PL/SQL交还给SQL引擎。
- 错误写法：
FOR r1 IN (SELECT id FROM t1) LOOP FOR r2 IN (SELECT x FROM t2 WHERE t2.ref_id = r1.id) LOOP ... END LOOP; END LOOP; - 正确路径一（首选）：用SQL JOIN一次性拉出所有关联数据：
FOR r IN (SELECT t1.id, t2.x FROM t1 JOIN t2 ON t1.id = t2.ref_id) LOOP ... END LOOP; - 正确路径二（需本地处理）：先
BULK COLLECT INTO取全量，再用索引遍历或FORALL批量DML；必须加LIMIT 1000防PGA溢出 - 注意：
%NOTFOUND对BULK COLLECT无效，必须用v_data.COUNT = 0判空
提前物化高频查询结果
当PL/SQL反复查同一张小表（如码表、配置表），每次都走SQL引擎纯属浪费——直接用INDEX BY VARCHAR2数组缓存，实现O(1)查找。
- 例如：
l_status_map('A') := 'Active'替代每次SELECT desc FROM sys_codes WHERE code = 'A' - 多字段组合键可用字符串拼接：
l_map(t1.dept_id || '|' || t1.role) := t2.value - 若被查表会动态更新，必须加版本戳或定时刷新机制，不能盲目缓存
- 避免在
FORALL里调用函数（如UPPER(v_data(i).name)），所有转换必须在FORALL外完成
什么时候不该硬套BULK COLLECT
批量不是银弹。逻辑强依赖上一行结果时（比如滚动累加、状态机流转），强行用集合会破坏语义——这种场景老实用FOR rec IN (SELECT ...) LOOP，再配合MOD(i, 100) = 0做中间提交。
- 数据量极小（
- 单次
BULK COLLECT超5万行且PGA受限（如OLTP系统限制256MB），会触发磁盘交换，此时坚持分批比退化成逐行更稳 -
FORALL下标必须连续；若中间删过元素，改用INDICES OF v_data
真正卡住的往往不是循环语法本身，而是没想清楚“这一步到底该由SQL引擎做，还是该由PL/SQL做”。驱动表选错、连接列缺索引、统计信息陈旧，这些都会让优化动作白费——先看AWR里ROWS_PROBED和ACCESS_PREDICATES，再动手改代码。
