1. 为什么你拿到的执行计划总是不对

Oracle 执行计划获取这件事，看起来只是敲一条explain plan for，但真正落到排查现场，问题往往出在「你以为拿到了真实计划，其实只是优化器在特定环境下的估算」。我见过太多案例：开发同学在测试库跑 EXPLAIN PLAN 显示走索引，生产库同样的 SQL 却全表扫描；或者用 AUTOTRACE 看到一堆统计信息，却分不清哪部分是真实执行、哪部分是预估。

这篇内容聚焦 Oracle 执行计划获取的几种常见方法——EXPLAIN PLAN、AUTOTRACE、DBMS_XPLAN、V$SQL_PLAN——讲清楚它们的适用场景与差异，同时结合 TaoToken 统一 Key/API 通道，聊聊在 AI 工具侧排查配置问题的思路。适合正在做 SQL 调优、需要快速定位执行计划获取失败或结果异常的 DBA 和开发同学。你会看到可直接复制的 EXPLAIN PLAN 与 DBMS_XPLAN 查询语句、AUTOTRACE 开启步骤，以及 AI 工具 settings.json / config.toml 骨架示例与验证动作。

先说结论：预估计划看 EXPLAIN PLAN，真实计划看 DBMS_XPLAN.DISPLAY_CURSOR，历史计划看 DISPLAY_AWR，开发调试用 AUTOTRACE，深度分析上 SQL_TRACE + TKPROF。选错方法，后面的调优方向全是错的。

2. 几种获取方法的适用场景与差异

2.1 EXPLAIN PLAN：只生成计划，不执行 SQL

EXPLAIN PLAN 是最轻量的方式。它把 SQL 作为输入，优化器生成执行计划后存入 PLAN_TABLE，整个过程不真正执行 SQL。这意味着两件事：第一，速度快、无副作用；第二，计划可能不准，因为当前环境与执行时环境不同、不考虑绑定变量数据类型、不做变量窥视。

操作上，先执行：

explain plan for select * from employees where department_id = 50;

然后从计划表读取：

select * from table(dbms_xplan.display);

如果你需要指定 plan table 或格式化输出，可以这样：

select * from table(dbms_xplan.display('PLAN_TABLE', null, 'BASIC +COST +PREDICATE'));

适用场景：SQL 还没执行、想快速看优化器倾向；或者在没有权限查动态性能视图时做初步判断。不适合：需要真实运行时统计信息的调优。

2.2 DBMS_XPLAN.DISPLAY_CURSOR：拿 library cache 里的真实计划

这是获取真实执行计划最常用的方法。SQL 执行后，计划缓存在 library cache 中，通过 sql_id 和 child_number 就能取出。先找游标：

select sql_id, child_number, sql_text from v$sql where sql_text like '%employees%';

如果 SQL 正在运行，从会话里拿：

select status, sql_id, sql_child_number from v$session where status = 'ACTIVE';

拿到 sql_id 后查计划：

select * from table(dbms_xplan.display_cursor('sql_id_value', child_number_value));

想看前一次执行的计划，用：

set serveroutput off select * from table(dbms_xplan.display_cursor(null, null, 'ALLSTATS LAST'));

注意set serveroutput off这行，否则 DBMS_XPLAN 的输出可能被 serveroutput 干扰。ALLSTATS LAST会带上 A-Rows、E-Rows 等运行时统计，是判断预估行数与实际行数偏差的关键。

2.3 DISPLAY_AWR：查历史执行计划

AWR 会定时把动态性能视图中的执行计划保存到 dba_hist_sql_plan。要查历史计划：

select * from table(dbms_xplan.display_awr('sql_id_value'));

适用场景：SQL 已经执行完很久，library cache 里已经被换出，但你想回溯当时的计划。前提是 AWR 快照还在保留期内，且 SQL 被 AWR 采集到。

2.4 AUTOTRACE：SQL*Plus 里的开发调试利器

AUTOTRACE 只能在 SQL*Plus 连接的 session 中使用，适合开发阶段快速测试。开启方式：

set autotrace on explain

几种模式对照：

TRACEONLY 模式下 SQL 不会真正返回结果集，适合大表测试。但要注意，AUTOTRACE 的统计信息来自 session 级统计，和真实生产负载有差异。

2.5 V$SQL_PLAN 与 SQL_TRACE

直接查 V$SQL_PLAN 可以拿到计划的行级明细：

select * from v$sql_plan where sql_id = 'sql_id_value';

更详细的统计在v$sql_plan_statistics_all。如果要跟踪绑定变量、等待事件等深度信息，用 SQL_TRACE：

alter session set sql_trace = true; -- 执行你的 SQL alter session set sql_trace = false;

跟踪其他会话：

exec dbms_system.set_sql_trace_in_session(sid, serial#, true); exec dbms_system.set_sql_trace_in_session(sid, serial#, false);

生成的 trace 文件用 TKPROF 转换：

tkprof inputfile.trc outputfile.txt

3. TaoToken 前置：统一 Key/API 通道的配置骨架

排查执行计划问题时，AI 工具侧的配置错误经常被忽略。比如你让 AI 助手帮你分析执行计划，结果请求根本没发出去，或者模型返回的内容和数据库无关。TaoToken 提供统一 Key/API 通道，把模型对话、Coding Plan、API Keys 等入口收敛到一套配置里，减少多工具切换时的配置漂移。

官网入口：https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=

API 地址：https://taotoken.net/api

在 AI 工具里配置时，核心是 base_url 和 api_key 两项。以 settings.json 为例：

{ "ai": { "base_url": "https://taotoken.net/api", "api_key": "你的统一Key", "model": "claude-sonnet-4-20250514" } }

如果用 config.toml：

[ai] base_url = "https://taotoken.net/api" api_key = "你的统一Key" model = "claude-sonnet-4-20250514"

配置完成后，先做一次最小验证：发一条简单请求，确认返回正常。如果返回 401，检查 Key 是否复制完整；如果返回 404，检查 base_url 是否多了或少了路径段。

4. 可复制配置与验证请求

4.1 执行计划获取的完整验证流程

假设你要排查一条慢 SQL，按下面步骤走：

第一步，用 EXPLAIN PLAN 快速看优化器倾向：

explain plan for select e.employee_id, e.salary, d.department_name from employees e join departments d on e.department_id = d.department_id where e.salary > 10000; select * from table(dbms_xplan.display);

第二步，实际执行 SQL 后，从 v$sql 找 sql_id：

select sql_id, child_number, executions, elapsed_time/1000000 as elapsed_sec from v$sql where sql_text like '%employees%departments%' order by last_active_time desc;

第三步，用 DISPLAY_CURSOR 拿真实计划带统计：

select * from table(dbms_xplan.display_cursor('你的sql_id', 0, 'ALLSTATS LAST'));

重点看 E-Rows 和 A-Rows 的偏差。如果某一步 E-Rows 是 1 而 A-Rows 是 10000，说明统计信息可能过期，或者绑定变量窥视导致计划不优。

第四步，如果 library cache 里已经没了，查 AWR：

select * from table(dbms_xplan.display_awr('你的sql_id'));

4.2 AI 工具侧验证动作

配置好 TaoToken 后，在 AI 工具里发一条测试请求，比如让它解释一段 EXPLAIN PLAN 输出。如果模型能正常返回分析内容，说明通道通了。如果报错，按错误码排查：

验证模型对话可以走模型对话入口；如果是长期编码或 Agent 场景，建议用 Coding Plan；需要管理 Key 就去 API Keys 页面；接入文档在 doc 里能查到完整参数说明。

5. 本篇常见错排查

5.1 EXPLAIN PLAN 结果与真实执行不一致

这是最常见的问题。原因通常是：绑定变量类型不同、变量窥视未触发、统计信息过期、或者执行环境参数差异。解决办法是改用 DISPLAY_CURSOR 拿真实计划，或者用explain plan for时配合set绑定变量模拟。

5.2 DISPLAY_CURSOR 返回空

先确认 sql_id 和 child_number 是否正确。如果 SQL 已经不在 library cache 里，DISPLAY_CURSOR 会返回空。这时候查 AWR 或者重新执行 SQL 后再查。另外注意set serveroutput off，否则输出可能被吞掉。

5.3 AUTOTRACE 开启失败

AUTOTRACE 需要 PLUSTRACE 角色和 PLAN_TABLE。如果报错SP2-0618: Cannot find the Session Identifier，说明没建 PLAN_TABLE。用@?/rdbms/admin/utlxplan.sql创建，然后授予 PLUSTRACE 角色。

5.4 AI 工具请求超时或返回无关内容

先检查 base_url 是否写成了带 UTM 的地址。API 调用应该用 https://taotoken.net/api，不要加查询参数。如果返回内容与数据库无关，检查 model 字段是否指向了正确的模型。另外确认网络环境能正常访问 API 地址。

5.5 TKPROF 输出乱码或格式错乱

TKPROF 对 trace 文件的编码敏感。如果输出乱码，检查数据库字符集和 trace 文件编码是否一致。另外 TKPROF 的参数顺序是tkprof inputfile outputfile，别写反了。

6. 继续排查与接入入口

执行计划获取这件事，核心是选对方法：预估用 EXPLAIN PLAN，真实用 DISPLAY_CURSOR，历史用 DISPLAY_AWR，开发调试用 AUTOTRACE，深度分析上 SQL_TRACE。AI 工具侧则要确保 TaoToken 的 base_url 和 api_key 配置正确，验证请求能正常返回。

如果你在配置过程中遇到接入问题，可以走 API Keys 和接入文档；想先验证模型是否正常工作，用模型对话入口；如果是长期编码或 Agent 场景，Coding Plan 更合适。把执行计划排查和 AI 工具配置这两条线都跑通，后面调优效率会高很多。