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只生成计划不执行 SQLEXPLAIN 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 AUTOTRACESQL*Plus 里的开发调试利器AUTOTRACE 只能在 SQL*Plus 连接的 session 中使用适合开发阶段快速测试。开启方式set autotrace on explain几种模式对照命令作用SET AUTOTRACE OFF不显示计划和统计信息默认模式SET AUTOTRACE ON EXPLAIN只显示优化器执行计划SET AUTOTRACE ON STATISTICS只显示统计信息SET AUTOTRACE ON执行计划和统计信息同时显示SET AUTOTRACE TRACEONLY不真正执行只显示预期计划同 explain planTRACEONLY 模式下 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_TRACEalter 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.txt3. TaoToken 前置统一 Key/API 通道的配置骨架排查执行计划问题时AI 工具侧的配置错误经常被忽略。比如你让 AI 助手帮你分析执行计划结果请求根本没发出去或者模型返回的内容和数据库无关。TaoToken 提供统一 Key/API 通道把模型对话、Coding Plan、API Keys 等入口收敛到一套配置里减少多工具切换时的配置漂移。官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI 地址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_idselect 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 里已经没了查 AWRselect * from table(dbms_xplan.display_awr(你的sql_id));4.2 AI 工具侧验证动作配置好 TaoToken 后在 AI 工具里发一条测试请求比如让它解释一段 EXPLAIN PLAN 输出。如果模型能正常返回分析内容说明通道通了。如果报错按错误码排查错误码可能原因处理401Key 无效或未携带检查 api_key 字段404base_url 路径错误确认是 https://taotoken.net/api429请求频率超限降低并发或稍后重试500服务端临时问题重试并观察验证模型对话可以走模型对话入口如果是长期编码或 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 工具配置这两条线都跑通后面调优效率会高很多。