如何优化PLSQL中的SQL_减少上下文切换与Context Switch原理

PL/SQL里频繁调用SELECT为什么慢

根本原因在于，每一次SELECT语句的执行，都会触发一次SQL引擎与PL/SQL引擎之间的上下文切换。这并非数据库本身性能不足，而是两种执行环境在反复“交接工作”：PL/SQL在自己的栈上运行，一旦需要查询数据，就必须把控制权交给SQL引擎；等结果返回，再切换回来。单次切换开销不大，但如果在循环里写SELECT ... INTO v_x FROM t WHERE id = i;并执行上万次，累积起来的切换开销就相当可观了。

典型的错误现象是：使用DBMS_PROFILER或DBMS_HPROF分析时，会发现sql execute的耗时占比极高，但单独对那条SQL做EXPLAIN PLAN却显示执行很快；或者在AWR报告中看到parse time elapsed或recursive cpu usage指标异常偏高。

• 常见场景：在循环中逐行查询配置表、进行数据校验或拼装数据（例如，在处理订单明细前，先循环查询每个客户的等级信息）。
• 核心原理：PL/SQL引擎本身无法原生执行SQL，必须委托给SQL引擎处理，每次委托都会产生固定的上下文切换开销（大约2–5微秒，但乘以万次循环后，就会升级为毫秒级的延迟）。
• 参数澄清：是否启用RESULT_CACHE对此类切换开销并无缓解作用——因为结果缓存优化的是数据检索本身，而非消除引擎间的切换过程。

用BULK COLLECT批量取代替单行SELECT INTO

核心思路是将N次单行查询压缩为一次批量拉取，从而直接消除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集合即可，无需再执行单条查询
END;

什么时候该用FORALL而不是FOR循环+单条DML

FORALL的真正价值并非“让循环变快”，而是将N次独立的DML语句调用打包成一次对SQL引擎的批量调用，从而一次性规避掉N次的上下文切换、SQL解析以及执行计划重用判断。它主要负责发送指令，本身不处理返回值（除非使用SA VE 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视图中的相关统计信息（准确的思路是，通过CPU used by this session与DB CPU的差值，再结合execute count来间接推算）。
• 使用DBMS_MONITOR.SESSION_TRACE_ENABLE开启10046级别的SQL跟踪，然后在跟踪文件中搜索PARSING IN CURSOR和EXEC #出现的频次——每一对通常就对应一次上下文切换。
• 从19c版本开始，可以利用DBMS_HPROF在FUNCTION层级更精确地看到sql execute的函数调用深度，这比旧版的DBMS_PROFILER更为准确。

真正棘手的是混合场景：例如，一个存储过程中既使用了BULK COLLECT进行批量操作，又夹杂了几处不得不进行的单次查询（比如获取系统时间戳、序列值）。在这种情况下，上下文切换并不会完全消失，只是其开销被整体性能提升所摊薄了。因此，优化重点不在于“彻底消灭”，而在于“精准识别并优化那些性价比最低、最不必要的切换点”。