应放弃PL/SQL嵌套循环，优先用SQL连接（如HASH JOIN）一次性处理关联逻辑，其次选BULK COLLECT+FORALL批量操作，必要时用INDEX BY TABLE模拟哈希查找。
直接改用哈希连接或集合操作，不是“替换语法”，而是放弃在pl/sql层做嵌套循环逻辑——因为99%的性能问题根源是把本该由sql引擎完成的连接/匹配，硬拖进pl/sql里用两层for循环逐行比对。
为什么PL/SQL嵌套循环比SQL慢一个数量级
每次外层循环取一条记录，内层就触发一次独立SQL执行（比如SELECT ... FROM t2 WHERE t2.id = :v1），等于做了N×M次单行查询。而SQL引擎的HASH JOIN或NESTED LOOPS是在C层一次性加载、分区、哈希探测，上下文切换开销归零。
- 典型症状：
DBMS_OUTPUT.PUT_LINE输出缓慢、V$SESSION_EVENT中SQL*Net message from client或library cache lock等待突增 - 真实代价：每轮循环至少2次用户态/内核态切换 + 1次SQL解析（未绑定变量时） + 网络往返（如远程调用）
- 别信“加索引就能救”——索引只能缓解内表扫描，但无法消除N×M次调用本身
用BULK COLLECT + FORALL替代双层FOR循环
当原逻辑是“遍历A表每条记录，查B表匹配项再更新/插入”，优先合并为单SQL，不行再退到批量集合操作。
- 错误写法：
FOR r1 IN (SELECT id, name FROM t1) LOOP FOR r2 IN (SELECT x FROM t2 WHERE t2.ref_id = r1.id) LOOP ... END LOOP; END LOOP; - 正确路径一（首选）：用
JOIN一次性拉出所有匹配数据：FOR r IN (SELECT t1.id, t1.name, t2.x FROM t1 JOIN t2 ON t1.id = t2.ref_id) LOOP ... END LOOP; - 正确路径二（需集合处理）：
BULK COLLECT INTO先取全量，再用FORALL批量DML：DECLARE TYPE t1_tab IS TABLE OF t1%ROWTYPE; t1_data t1_tab; BEGIN SELECT * BULK COLLECT INTO t1_data FROM t1 WHERE ...; FORALL i IN 1..t1_data.COUNT UPDATE t2 SET status = 'PROCESSED' WHERE ref_id = t1_data(i).id; END; - 注意：
BULK COLLECT默认无限制，大数据量必须加LIMIT n防PGA溢出
什么时候该强制用HASH JOIN而不是NL
不是看“要不要嵌套循环”，而是看驱动结果集大小和内表访问方式——如果PL/SQL循环模拟的是NL语义，但实际数据分布根本不适合NL，强行保留只会放大缺陷。
- 触发条件：
EXPLAIN PLAN显示NESTED LOOPS，但ROWS_PROBED远大于ROWS_PROCESSED（比如内表被探测5万次，仅返回200行） - 验证方法：在SQL中加
/*+ USE_HASH(t1 t2) */hint对比逻辑读，若buffer_gets下降50%以上，说明NL是伪优化 - 关键限制：
HASH JOIN不支持ORDER BY保序，也不支持ROWNUM截断；若业务强依赖“先返回前几行”，NL仍是唯一选择 - 隐性成本：哈希连接需内存（
PGA_AGGREGATE_TARGET），小内存环境可能降级为SORT MERGE
用关联数组（INDEX BY TABLE）模拟哈希查找
当必须在PL/SQL中做“查找匹配”且无法改SQL时，用INDEX BY VARCHAR2或INDEX BY NUMBER替代内层循环——这是最接近哈希查找的PL/SQL原生方案。
- 示例：
DECLARE TYPE t2_hash IS TABLE OF t2%ROWTYPE INDEX BY PLS_INTEGER; t2_cache t2_hash; BEGIN -- 一次性载入内表（按连接键索引） FOR r IN (SELECT * FROM t2) LOOP t2_cache(r.ref_id) := r; -- ref_id作为下标 END LOOP; <p>-- 外层循环直接O(1)查找 FOR r1 IN (SELECT id, name FROM t1) LOOP IF t2_cache.EXISTS(r1.id) THEN -- 匹配成功，无需内层循环 NULL; END IF; END LOOP; END; - 限制：键类型必须是
PLS_INTEGER、VARCHAR2或DATE；超大集合会吃光PGA - 比嵌套循环快，但比纯SQL慢——它只是把N×M降到N，而SQL能降到N+M
真正卡住人的从来不是“会不会写FORALL”，而是没意识到：只要PL/SQL里出现两层FOR套SELECT，就已经站在了性能悬崖边上。先问自己一句——这个连接逻辑，SQL引擎能不能一步做完？不能，再考虑集合；能，就别碰PL/SQL循环。
