逻辑读取次数高源于重复访问缓冲区数据块，主因是嵌套循环查询、未批量处理、高频小表未缓存及循环内重复计算；应改用join、bulk collect+forall、内存缓存和循环外预计算。
逻辑读取次数高，本质是数据库反复访问缓冲区里的数据块。不是SQL写得慢，而是执行方式让相同数据块被重复计数——比如嵌套循环里每轮都查一次小表，1000次循环就产生1000次逻辑读，哪怕那张表只有5行。
用JOIN代替嵌套循环查表
双层 FOR 循环（尤其外层游标 + 内层 SELECT INTO）是逻辑读飙升的头号原因。每次内层查询都走完整解析→执行→获取流程，哪怕数据已在 buffer cache，仍计入逻辑读。
- 错误写法：
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; - 正确做法：改用单次
JOIN拉全量，让优化器在SQL引擎层完成关联：FOR r IN (SELECT t1.id, t2.x FROM t1 JOIN t2 ON t1.id = t2.ref_id) LOOP ... END LOOP; - 注意：如果业务要求必须逐行处理（如滚动累加、状态依赖），JOIN 不适用，但此时应确认是否真无法改写——很多所谓“依赖”其实只是代码惯性
BULK COLLECT + FORALL 批量替代逐行DML
把多次单行 INSERT/UPDATE 合并为一次批量操作，能直接砍掉90%以上逻辑读。关键不是语法替换，而是把控制权交还给SQL引擎。
- 先用
BULK COLLECT INTO把数据一次性拉进PL/SQL集合，再用FORALL批量提交；必须加LIMIT 1000防PGA溢出 -
%NOTFOUND对BULK COLLECT无效，判空要用v_data.COUNT = 0 - 避免在
FORALL里调用函数（如UPPER(v_data(i).name)），所有转换必须在FORALL外完成
高频小表查询结果缓存到INDEX BY数组
反复查码表、配置表这类静态或低频更新的小表，每次走SQL引擎纯属浪费。直接缓存到内存数组，实现O(1)查找。
- 例如：把
SELECT desc FROM sys_codes WHERE code = 'A'改为用l_map('A') := 'Active'查找 - 多字段组合键可用字符串拼接：
l_map(t1.dept_id || '|' || t1.role) := t2.value - 若被查表会动态更新，必须加版本戳或定时刷新机制，不能盲目缓存
提前计算循环外可确定的值
循环里反复调用 GETDATE()、查配置表、拼日期字符串等操作，每次都是实打实开销。数据库不会帮你缓存这些结果。
- 正确做法：在循环前一次性算好，存入变量，如
SELECT @base_rate = value FROM config_table WHERE key = 'exchange_rate';，后续直接用@base_rate - 警惕
ISNULL()套多层子查询、GETDATE() + N这类组合，在循环里每跑一次就多一次解析+执行 - 如果必须动态取值（如依赖上一轮结果），至少用
SELECT @var = column FROM替代SELECT TOP 1这类带排序/限制的写法
真正难的不是知道该用 JOIN 或 BULK COLLECT，而是判断哪些“必须逐行”的逻辑其实可以重构——比如状态机流转，有时只需加个中间表记录断点，就能转成批量驱动。这点最容易被忽略，也最影响长期维护成本。
