存储过程执行慢而SQL快，主因是参数嗅探或执行计划失真；应通过SQL Trace捕获真实执行路径，结合tkprof分析等待事件、绑定变量及索引使用情况精准定位。
存储过程执行慢，但单独跑 sql 很快？别急着改逻辑，先确认是不是执行计划“骗”了你——sql trace 是 oracle 原生、低侵入、能抓到真实执行路径的手段，比看 pl/sql 工具里的“执行计划”更可靠。
怎么开 SQL Trace 并拿到真实执行数据
关键不是“开了没”，而是“开对了会话、抓准了范围”。PL/SQL Developer 或 SQL*Plus 里直接 ALTER SESSION SET SQL_TRACE = TRUE 只能捕获当前会话后续所有语句，容易混入干扰项。更稳妥的做法是：先定位目标会话 SID 和 SERIAL#（查 v$session，过滤你的用户名和程序名），再用 DBA 权限执行：
EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE(session_id => 123, serial_num => 4567, waits => TRUE, binds => TRUE);
其中 waits = TRUE 记录等待事件（比如 db file sequential read 卡在哪一行），binds = TRUE 抓绑定变量值——这对判断隐式转换是否发生至关重要。Trace 文件默认生成在 user_dump_dest 目录下，用 tkprof 格式化后才可读：
tkprof ora_123456.trc output.txt sort='(prsela,fchela,exeela)'
sort 参数按解析、获取、执行耗时排序，能快速揪出最拖后腿的那条语句。
Trace 里最该盯住的三类信号
格式化后的 tkprof 输出不是全看，重点扫这三块：
-
Rows列远小于Execs：说明大量执行只返回 0 行，可能是条件写错或索引失效 - 出现
MISS in library cache多次：同一条 SQL 被反复硬解析，检查是否用了字面量拼接（如'WHERE id = ' || v_id）而非绑定变量 - 某条语句的
Elapsed高但CPU低、Waits高：大概率卡在 I/O 或锁上，接着查v$session_wait对应SID
特别注意：如果 trace 显示某条 UPDATE 的 Rows 是 1，但 Buffers（逻辑读）高达几十万，基本可以断定它没走索引——哪怕表上有索引，也可能是字段类型不匹配导致隐式转换（比如 NVARCHAR2 变量去等 VARCHAR2 字段）。
为什么不用 AUTOTRACE 或 EXPLAIN PLAN
EXPLAIN PLAN FOR 只是预估，不实际执行；AUTOTRACE TRACEONLY 虽执行，但会绕过真实绑定变量值，用 NULL 或默认值代入，导致执行计划失真。而 SQL Trace 捕获的是真实运行时行为，包括：
- 实际用了哪个索引（甚至是否用了索引合并）
- 每行数据被访问了多少次（
Buffer Gets异常高往往意味着嵌套循环没控制好驱动表） - 是否存在大量
recursive calls（比如触发器、物化视图刷新引发的隐式 SQL）
一个典型坑：存储过程里用 FOR rec IN (SELECT ...) 循环，trace 会暴露外层循环每次都在重复解析同一查询——这时应该把游标声明为 STATIC 或显式 OPEN/FETCH 并复用。
Trace 后下一步不是改 SQL，而是看绑定变量值
很多性能问题藏在变量里：tkprof 输出末尾的 Bind variable information 区域必须细看。例如发现某次调用传入的 :B1 = 'ABC '（带空格），而字段是 VARCHAR2(10)，Oracle 会自动 RTRIM 再比较，导致无法使用索引。又或者 :B1 是数字字符串 '123'，但字段是 NUMBER，触发隐式转换。
这类问题不会在开发环境暴露——因为测试数据短、分布均匀；一到生产，数据倾斜+类型不一致，执行计划就彻底跑偏。所以 trace 不只是找“哪句慢”，更是验证“为什么慢得和预期不一样”。
