PL/SQL里频繁调用SELECT为什么慢
因为每次select语句执行，都会触发一次sql引擎与pl/sql引擎之间的上下文切换（context switch）。这不是“数据库卡”，而是两种执行环境来回交班——pl/sql在自己栈上跑，查数据得把控制权交给sql引擎；结果返回，再切回来。一次两次不明显，循环里写select ... into v_x from t where id = i;跑1万次，就是1万次切换开销。
常见错误现象：DBMS_PROFILER或DBMS_HPROF显示sql execute耗时占比极高，但单条SQL本身EXPLAIN PLAN很快；AWR里parse time elapsed或recursive cpu usage异常高。
- 使用场景：循环中逐行查配置、校验、拼装数据（比如处理订单明细前先查客户等级）
- 根本原因：PL/SQL引擎无法原生执行SQL，必须委托SQL引擎，每次委托都有固定开销（约2–5μs，但乘以万级就成毫秒级延迟）
- 参数差异：是否启用
RESULT_CACHE对这类切换无缓解作用——缓存的是结果，不是切换本身
用BULK COLLECT批量取代替单行SELECT INTO
把N次单行查询压成1次批量拉取，直接砍掉N−1次上下文切换。关键是别只改语法，得配合集合类型和边界控制。
实操建议：
- 声明
TYPE t_id_list IS TABLE OF NUMBER INDEX BY PLS_INTEGER;或用INDEX BY BINARY_INTEGER（兼容老版本） -
BULK COLLECT INTO后立刻检查COUNT，避免空集合导致后续逻辑错位 - 加
LIMIT子句防内存溢出：FETCH c1 BULK COLLECT INTO l_ids LIMIT 1000;，尤其在游标大数据量时 - 不要在
BULK COLLECT后直接用FORALL UPDATE操作同一张表且没加WHERE CURRENT OF——可能引发ORA-01002（fetch out of sequence）
示例片段：
DECLARE
TYPE t_name_tab IS TABLE OF VARCHAR2(100);
l_names t_name_tab;
BEGIN
SELECT ename BULK COLLECT INTO l_names
FROM emp WHERE deptno = 10;
-- 后续用l_names.COUNT遍历，不再查表
END;
什么时候该用FORALL而不是FOR循环+单条DML
FORALL不是“让循环变快”，而是把N次DML语句打包成1次SQL引擎调用，从而规避N次上下文切换+解析+执行计划重用判断。它只管发指令，不管返回值（除非加SAVE EXCEPTIONS）。
容易踩的坑：
-
FORALL i IN 1..l_ids.COUNT中的索引必须连续——如果集合是稀疏的（比如DELETE过中间元素），会报ORA-22160 -
FORALL不能嵌套，也不能放在IF分支里动态决定是否执行（语法报错） - 绑定变量只能是集合，不能是标量：
FORALL i IN 1..n INSERT INTO t(x) VALUES (l_vals(i))合法；VALUES (v_single)非法 - 性能影响：未开启
PLSQL_OPTIMIZE_LEVEL=2（默认）时，FORALL优化可能被弱化
Context Switch在12c+的UTL_CALL_STACK里看不见？
对。UTL_CALL_STACK只反映PL/SQL调用栈，不记录SQL引擎内部动作。想定量看切换开销，得靠底层指标：
- 查
V$SESSTAT中context switches（准确名是CPU used by this session与DB CPU差值，再结合execute count反推） - 用
DBMS_MONITOR.SESSION_TRACE_ENABLE开10046 trace，搜PARSING IN CURSOR和EXEC #出现频次——每对对应一次切换 - 19c起可用
DBMS_HPROF的FUNCTION层级看到sql execute函数调用深度，比老版DBMS_PROFILER更准
真正难处理的是混合场景：比如一个存储过程里既有BULK COLLECT，又有几处不得不单查的SELECT（如查系统时间戳、序列值）。这时候上下文切换不会消失，只是被摊薄——重点不在“消灭”，而在“识别哪几处切得最冤”。
