一条慢 SQL 拿到手很多人的第一反应是看执行计划但dbms_xplan.display_cursor(null, null, iostats last -predicate -note)才是把“真实执行计划”连同 A-Rows、A-Time 一起打出来的方法。我们最需要回答的问题是这十几行数字里哪一步 Rows 偏差最大、Starts 是否异常、A-Time 花在哪个节点Codex 适合干这个活而 Codex 的模型通道我用的是 TaoToken——先到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建一把 API Key再把 Codex 的 Base URL 填成 https://taotoken.net/api。整个链路里display_cursor仍在 Oracle 上执行Codex 只负责读执行计划文本、指出问题所在。下面把完整操作过一遍。1. 为什么 explain plan 不够要 display_cursor 打出来的真实执行计划1.1 预估计划是预演真实计划是回放EXPLAIN PLAN FOR生成的是基于统计信息和优化器估算出来的执行计划它只回答“优化器打算怎么做”。Oracle 真正执行 SQL 时行数、耗时、缓冲区访问次数都会被记录下来但这些现场数据只有display_cursor能看到。DISPLAY_CURSOR函数从库缓存里取出对应游标的真实执行路径配合iostats修饰符还能输出每一步的Starts这一步被启动了多少次E-Rows优化器预估返回多少行A-Rows实际返回多少行A-Time这一步累计耗时Buffers这一步缓冲区访问次数当 E-Rows 和 A-Rows 差距很大时问题通常出在统计数据不准确或者连接方式选错而不是单纯“缺索引”。1.2 几行输出里藏着最关键的两个信号我拿到一份带iostats的display_cursor结果会先找两个信号。第一个信号是 A-Rows 远大于 E-Rows。比如某个 TABLE ACCESS FULL 预估 14 行实际扫出 120 行说明优化器对活跃数据量的估计偏低下一步多半要考虑的是统计信息刷新而不是加索引。第二个信号是 Starts 远大于 1。嵌套循环里内层表如果被反复访问Starts 会等于驱动表返回的行数。此时即使单次索引扫描只要 0.01 秒乘上 500 次也会变成大瓶颈。这些对比给 Codex 读它的强项是“逐行对比异常值”并翻译成优化建议但它不会也不能直连你的 Oracle 库。1.3 Codex 在排障链路里的分工Codex 只处理粘贴给它的文本不连接生产库不替你执行任何 SQL。它要做的是对比 E-Rows 与 A-Rows标出偏差最大的操作结合 Starts 判断嵌套循环驱动方向是否合理根据 A-Time 和 Buffers 指出耗时热点给出“该重新收集统计信息”还是“该换连接方式”这类建议所以执行计划怎么抓、在哪里抓仍然是 DBA 自己的事。2. 先拿一把 TaoToken 的 Key再把 Codex 指到统一 API 通道2.1 打开官网创建 API Key在配置 Codex 之前先到 TaoToken 注册账号进入控制台创建 API Key。这把 Key 就是 Codex 访问模型对话通道的凭证。创建完成后先把 Key 复制到本地临时文件里后面填到环境变量。注意 Key 只在创建时完整显示一次页面刷新之后就看不到了。2.2 修改 Codex 的 ~/.codex/config.tomlCodex 的模型通道配置在~/.codex/config.toml。注意 Codex 不认ANTHROPIC_BASE_URL那套环境变量那是 Claude Code 的写法。Codex 认的是model_provider段。在配置文件里追加一个自定义 provider指向 TaoTokenmodel YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY这里有两个关键点base_url只填https://taotoken.net/api末尾不要加/v1model填什么以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场当时列的模型 ID 为准不要自己编造带日期后缀的 ID如果你的 Codex 版本要求指定wire_api填chat不确定就用默认值能跑通就别乱加字段。2.3 把 Key 放进环境变量provider 里的env_key TAOTOKEN_API_KEY表示 Codex 会从同名环境变量读取真实 Key。打开终端导出export TAOTOKEN_API_KEYYOUR_API_KEY重启 Codex 后发一句“回复 OK”做连通测试。如果返回 401说明 Key 没复制完整如果提示模型找不到回模型广场重新复制模型 ID。3. 在 SQL*Plus 里用 display_cursor 抓真实执行计划3.1 先让 SQL 带着实时统计信息跑一次display_cursor能输出 A-Rows 和 A-Time 的前提是 SQL 执行时记录了运行时统计。有两种开启方式。第一种是会话级修改把当前会话的statistics_level设为allalter session set statistics_levelall;这样当前会话里所有后续 SQL 都会带上统计信息适合专门调试某一条慢 SQL。第二种是语句级提示只影响目标 SQL对其他会话和语句完全无副作用SELECT /* gather_plan_statistics */ d.dname, e.ename, e.sal FROM emp e JOIN dept d ON e.deptno d.deptno WHERE d.loc DALLAS ORDER BY e.sal DESC;生产环境我一般用第二种。修改会话级参数需要小心调试完要记得恢复alter session set statistics_leveltypical;提示如果你的库是 10g R1iostats参数还不存在要用run_stats_last代替。确认版本可以用select * from v$version where rownum 2;。3.2 执行完目标 SQL立刻调 display_cursor目标 SQL 跑完之后在同一个会话里执行set pagesize 0 set linesize 200 select * from table(dbms_xplan.display_cursor(null, null, iostats last -predicate -note));null, null的含义是“当前会话最后一条 SQL 的默认子游标”。输出大致长这样列顺序可能因版本不同略有差异SQL_ID 4k2m8x9y0z1a, child number 0 -------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | -------------------------------------------------------------- | 1 | NESTED LOOPS | | 1 | 14 | 120 | 00:00:00.35 | | 2 | TABLE ACCESS FULL | EMP | 1 | 14 | 120 | 00:00:00.02 | |* 3 | INDEX UNIQUE SCAN | PK_DEPT | 120 | 1 | 1 | 00:00:00.30 | --------------------------------------------------------------把输出完整复制下来包括头部 SQL_ID、中间表格、Predicate Information 和 Note 部分。3.3 要分析历史 SQL 时先从 v$sql 拿 SQL_ID如果目标 SQL 已经不在当前会话里或者你想分析其他会话留下的游标就先查 SQL_IDselect sql_id, child_number, sql_text from v$sql where sql_text like %DALLAS% and sql_text not like %from v$sql%;拿到 SQL_ID 后把它作为display_cursor的第一个参数select * from table(dbms_xplan.display_cursor(4k2m8x9y0z1a, null, iostats last -predicate -note));这一步对应原文通过V$SQL查父游标的做法。SQL_ID 和执行计划要一起给 Codex否则它无法确认你给的是哪个游标尤其是存在多个 child number 时。4. 把执行计划连同 SQL_ID 贴给 Codex提示词模板4.1 给 Codex 的完整提问模板复制以下提示词把方括号里的内容替换成你的实际数据这是一条 Oracle SQL 的真实执行计划SQL_ID4k2m8x9y0z1a。 请按下面三点分析 1. 逐行对比 E-Rows 和 A-Rows标出偏差超过 10 倍的操作。 2. 指出 Starts 大于 1 且所在层级异常的步骤说明是否存在驱动顺序错误或数据被反复访问。 3. 根据 A-Time 和 Buffers指出最耗时的操作并判断是统计信息过期、连接方式不当还是索引缺失。 只分析我提供的文本不要假设你能连接数据库不要给需要数据库权限的指令。 执行计划如下 SQL_ID 4k2m8x9y0z1a, child number 0 -------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | -------------------------------------------------------------- | 1 | NESTED LOOPS | | 1 | 14 | 120 | 00:00:00.35 | | 2 | TABLE ACCESS FULL | EMP | 1 | 14 | 120 | 00:00:00.02 | |* 3 | INDEX UNIQUE SCAN | PK_DEPT | 120 | 1 | 1 | 00:00:00.30 | -------------------------------------------------------------- Predicate Information: 3 - access(E.DEPTNOD.DEPTNO)这是我实际在用的模板。Codex 收到后通常先给你讲嵌套循环的驱动逻辑然后指出第 3 行 Starts120 意味着 PK_DEPT 被访问了 120 次单次访问很快但累计耗时最长。4.2 追问比一次到位更实用第一轮回复往往只做了“偏差标注”你还要追问一句针对上面偏差最大的两步分别给出改写 SQL 或收集统计信息的具体操作建议。它会给出两种方向统计信息过期就建议重新收集连接顺序有误就建议调整驱动表或用 HINT。收到 HINT 建议时不要直接让它把 SQL 改完而是让 Codex 解释为什么这个 HINT 适合当前 A-Rows 分布再决定是否采用。4.3 一次可以贴多组执行计划对比如果同一业务有两条 SQL 行为相似把两组display_cursor输出都贴进去让它对比两条路径在同一个库上的实际表现差异。Codex 对这种“并排对比”处理得比人快结论也更直接。5. 排障Codex 解读执行计划时最容易出现的三类情况5.1 没有 A-Rows 列Codex 无从判断这是最常踩的坑。如果你忘了开统计信息display_cursor输出里只有 E-Rows 和 Cost没有 A-RowsCodex 会直接告诉你“无法从文本中确认实际行数”。解决办法就是回到第 3 章加上gather_plan_statistics提示重新执行目标 SQL再调一次display_cursor。5.2 Starts 远大于 1 的嵌套循环格式化的输出里Starts120 而父节点 Starts1说明这里被嵌套循环触发了 120 次。Codex 一般会判断驱动表选择有误外层数据量没有预估的那么小导致内层索引反复进入。这种情况通常让 Codex 对照 E-Rows 和 A-Rows 分析驱动表基数是否被低估而不是上来就换连接方式。如果外层表实际只有 120 行内层走索引成本不高问题可能出在别的地方。5.3 E-Rows 严重小于 A-Rows优化器预估返回 1 行实际返回几万行。Codex 给的建议大概率是重新收集表或索引的统计信息BEGIN DBMS_STATS.GATHER_TABLE_STATS( ownname SCOTT, tabname EMP, cascade TRUE ); END; /这段代码由你在 SQL*Plus 里执行Codex 不会也不应该直接操作你的数据库。执行完后再抓一次执行计划通常 A-Rows 和 E-Rows 的差距会明显收敛。5.4 Codex 返回 401 或 model not found401 表示 Key 或通道配置有问题。回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 控制台确认 Key 是否创建成功检查环境变量里有没有多余的空格再试一次。model not found 表示模型 ID 配错了。去模型广场复制完整 ID不要自己拼接版本号或日期后缀。Base URL 再次确认是https://taotoken.net/api不是带/v1的地址也不是官网落地页这两个容易混。6. 跑通后回 TaoToken 控制台对一下这次调用整条链路跑通后先到 TaoToken 模型对话 用同一把 Key 发一条消息确认 Codex 用的 Base URL 和模型 ID 都没填错。主要看对话是否正常返回、控制台里是否有对应的请求记录。如果准备把执行计划解释做成日常排障动作可以打开 Coding Plan 看看长期用量够不够Key 的管理统一在 控制台 API Keys 里操作。拿到 Key 后Codex 就能通过 TaoToken 读懂display_cursor的真实输出把 A-Rows 与 E-Rows 的偏差逐行列出来。你只需要在 SQL*Plus 里跑完 SQL把执行计划贴回去剩下的偏差定位交给它省掉在十几个节点里肉眼找异常值的时间。
一条慢 SQL 拿到手很多人的第一反应是看执行计划但dbms_xplan.display_cursor(null, null, iostats last -predicate -note)才是把“真实执行计划”连同 A-Rows、A-Time 一起打出来的方法。我们最需要回答的问题是这十几行数字里哪一步 Rows 偏差最大、Starts 是否异常、A-Time 花在哪个节点Codex 适合干这个活而 Codex 的模型通道我用的是 TaoToken——先到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建一把 API Key再把 Codex 的 Base URL 填成 https://taotoken.net/api。整个链路里display_cursor仍在 Oracle 上执行Codex 只负责读执行计划文本、指出问题所在。下面把完整操作过一遍。1. 为什么 explain plan 不够要 display_cursor 打出来的真实执行计划1.1 预估计划是预演真实计划是回放EXPLAIN PLAN FOR生成的是基于统计信息和优化器估算出来的执行计划它只回答“优化器打算怎么做”。Oracle 真正执行 SQL 时行数、耗时、缓冲区访问次数都会被记录下来但这些现场数据只有display_cursor能看到。DISPLAY_CURSOR函数从库缓存里取出对应游标的真实执行路径配合iostats修饰符还能输出每一步的Starts这一步被启动了多少次E-Rows优化器预估返回多少行A-Rows实际返回多少行A-Time这一步累计耗时Buffers这一步缓冲区访问次数当 E-Rows 和 A-Rows 差距很大时问题通常出在统计数据不准确或者连接方式选错而不是单纯“缺索引”。1.2 几行输出里藏着最关键的两个信号我拿到一份带iostats的display_cursor结果会先找两个信号。第一个信号是 A-Rows 远大于 E-Rows。比如某个 TABLE ACCESS FULL 预估 14 行实际扫出 120 行说明优化器对活跃数据量的估计偏低下一步多半要考虑的是统计信息刷新而不是加索引。第二个信号是 Starts 远大于 1。嵌套循环里内层表如果被反复访问Starts 会等于驱动表返回的行数。此时即使单次索引扫描只要 0.01 秒乘上 500 次也会变成大瓶颈。这些对比给 Codex 读它的强项是“逐行对比异常值”并翻译成优化建议但它不会也不能直连你的 Oracle 库。1.3 Codex 在排障链路里的分工Codex 只处理粘贴给它的文本不连接生产库不替你执行任何 SQL。它要做的是对比 E-Rows 与 A-Rows标出偏差最大的操作结合 Starts 判断嵌套循环驱动方向是否合理根据 A-Time 和 Buffers 指出耗时热点给出“该重新收集统计信息”还是“该换连接方式”这类建议所以执行计划怎么抓、在哪里抓仍然是 DBA 自己的事。2. 先拿一把 TaoToken 的 Key再把 Codex 指到统一 API 通道2.1 打开官网创建 API Key在配置 Codex 之前先到 TaoToken 注册账号进入控制台创建 API Key。这把 Key 就是 Codex 访问模型对话通道的凭证。创建完成后先把 Key 复制到本地临时文件里后面填到环境变量。注意 Key 只在创建时完整显示一次页面刷新之后就看不到了。2.2 修改 Codex 的 ~/.codex/config.tomlCodex 的模型通道配置在~/.codex/config.toml。注意 Codex 不认ANTHROPIC_BASE_URL那套环境变量那是 Claude Code 的写法。Codex 认的是model_provider段。在配置文件里追加一个自定义 provider指向 TaoTokenmodel YOUR_MODEL_ID model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY这里有两个关键点base_url只填https://taotoken.net/api末尾不要加/v1model填什么以 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场当时列的模型 ID 为准不要自己编造带日期后缀的 ID如果你的 Codex 版本要求指定wire_api填chat不确定就用默认值能跑通就别乱加字段。2.3 把 Key 放进环境变量provider 里的env_key TAOTOKEN_API_KEY表示 Codex 会从同名环境变量读取真实 Key。打开终端导出export TAOTOKEN_API_KEYYOUR_API_KEY重启 Codex 后发一句“回复 OK”做连通测试。如果返回 401说明 Key 没复制完整如果提示模型找不到回模型广场重新复制模型 ID。3. 在 SQL*Plus 里用 display_cursor 抓真实执行计划3.1 先让 SQL 带着实时统计信息跑一次display_cursor能输出 A-Rows 和 A-Time 的前提是 SQL 执行时记录了运行时统计。有两种开启方式。第一种是会话级修改把当前会话的statistics_level设为allalter session set statistics_levelall;这样当前会话里所有后续 SQL 都会带上统计信息适合专门调试某一条慢 SQL。第二种是语句级提示只影响目标 SQL对其他会话和语句完全无副作用SELECT /* gather_plan_statistics */ d.dname, e.ename, e.sal FROM emp e JOIN dept d ON e.deptno d.deptno WHERE d.loc DALLAS ORDER BY e.sal DESC;生产环境我一般用第二种。修改会话级参数需要小心调试完要记得恢复alter session set statistics_leveltypical;提示如果你的库是 10g R1iostats参数还不存在要用run_stats_last代替。确认版本可以用select * from v$version where rownum 2;。3.2 执行完目标 SQL立刻调 display_cursor目标 SQL 跑完之后在同一个会话里执行set pagesize 0 set linesize 200 select * from table(dbms_xplan.display_cursor(null, null, iostats last -predicate -note));null, null的含义是“当前会话最后一条 SQL 的默认子游标”。输出大致长这样列顺序可能因版本不同略有差异SQL_ID 4k2m8x9y0z1a, child number 0 -------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | -------------------------------------------------------------- | 1 | NESTED LOOPS | | 1 | 14 | 120 | 00:00:00.35 | | 2 | TABLE ACCESS FULL | EMP | 1 | 14 | 120 | 00:00:00.02 | |* 3 | INDEX UNIQUE SCAN | PK_DEPT | 120 | 1 | 1 | 00:00:00.30 | --------------------------------------------------------------把输出完整复制下来包括头部 SQL_ID、中间表格、Predicate Information 和 Note 部分。3.3 要分析历史 SQL 时先从 v$sql 拿 SQL_ID如果目标 SQL 已经不在当前会话里或者你想分析其他会话留下的游标就先查 SQL_IDselect sql_id, child_number, sql_text from v$sql where sql_text like %DALLAS% and sql_text not like %from v$sql%;拿到 SQL_ID 后把它作为display_cursor的第一个参数select * from table(dbms_xplan.display_cursor(4k2m8x9y0z1a, null, iostats last -predicate -note));这一步对应原文通过V$SQL查父游标的做法。SQL_ID 和执行计划要一起给 Codex否则它无法确认你给的是哪个游标尤其是存在多个 child number 时。4. 把执行计划连同 SQL_ID 贴给 Codex提示词模板4.1 给 Codex 的完整提问模板复制以下提示词把方括号里的内容替换成你的实际数据这是一条 Oracle SQL 的真实执行计划SQL_ID4k2m8x9y0z1a。 请按下面三点分析 1. 逐行对比 E-Rows 和 A-Rows标出偏差超过 10 倍的操作。 2. 指出 Starts 大于 1 且所在层级异常的步骤说明是否存在驱动顺序错误或数据被反复访问。 3. 根据 A-Time 和 Buffers指出最耗时的操作并判断是统计信息过期、连接方式不当还是索引缺失。 只分析我提供的文本不要假设你能连接数据库不要给需要数据库权限的指令。 执行计划如下 SQL_ID 4k2m8x9y0z1a, child number 0 -------------------------------------------------------------- | Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | -------------------------------------------------------------- | 1 | NESTED LOOPS | | 1 | 14 | 120 | 00:00:00.35 | | 2 | TABLE ACCESS FULL | EMP | 1 | 14 | 120 | 00:00:00.02 | |* 3 | INDEX UNIQUE SCAN | PK_DEPT | 120 | 1 | 1 | 00:00:00.30 | -------------------------------------------------------------- Predicate Information: 3 - access(E.DEPTNOD.DEPTNO)这是我实际在用的模板。Codex 收到后通常先给你讲嵌套循环的驱动逻辑然后指出第 3 行 Starts120 意味着 PK_DEPT 被访问了 120 次单次访问很快但累计耗时最长。4.2 追问比一次到位更实用第一轮回复往往只做了“偏差标注”你还要追问一句针对上面偏差最大的两步分别给出改写 SQL 或收集统计信息的具体操作建议。它会给出两种方向统计信息过期就建议重新收集连接顺序有误就建议调整驱动表或用 HINT。收到 HINT 建议时不要直接让它把 SQL 改完而是让 Codex 解释为什么这个 HINT 适合当前 A-Rows 分布再决定是否采用。4.3 一次可以贴多组执行计划对比如果同一业务有两条 SQL 行为相似把两组display_cursor输出都贴进去让它对比两条路径在同一个库上的实际表现差异。Codex 对这种“并排对比”处理得比人快结论也更直接。5. 排障Codex 解读执行计划时最容易出现的三类情况5.1 没有 A-Rows 列Codex 无从判断这是最常踩的坑。如果你忘了开统计信息display_cursor输出里只有 E-Rows 和 Cost没有 A-RowsCodex 会直接告诉你“无法从文本中确认实际行数”。解决办法就是回到第 3 章加上gather_plan_statistics提示重新执行目标 SQL再调一次display_cursor。5.2 Starts 远大于 1 的嵌套循环格式化的输出里Starts120 而父节点 Starts1说明这里被嵌套循环触发了 120 次。Codex 一般会判断驱动表选择有误外层数据量没有预估的那么小导致内层索引反复进入。这种情况通常让 Codex 对照 E-Rows 和 A-Rows 分析驱动表基数是否被低估而不是上来就换连接方式。如果外层表实际只有 120 行内层走索引成本不高问题可能出在别的地方。5.3 E-Rows 严重小于 A-Rows优化器预估返回 1 行实际返回几万行。Codex 给的建议大概率是重新收集表或索引的统计信息BEGIN DBMS_STATS.GATHER_TABLE_STATS( ownname SCOTT, tabname EMP, cascade TRUE ); END; /这段代码由你在 SQL*Plus 里执行Codex 不会也不应该直接操作你的数据库。执行完后再抓一次执行计划通常 A-Rows 和 E-Rows 的差距会明显收敛。5.4 Codex 返回 401 或 model not found401 表示 Key 或通道配置有问题。回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 控制台确认 Key 是否创建成功检查环境变量里有没有多余的空格再试一次。model not found 表示模型 ID 配错了。去模型广场复制完整 ID不要自己拼接版本号或日期后缀。Base URL 再次确认是https://taotoken.net/api不是带/v1的地址也不是官网落地页这两个容易混。6. 跑通后回 TaoToken 控制台对一下这次调用整条链路跑通后先到 TaoToken 模型对话 用同一把 Key 发一条消息确认 Codex 用的 Base URL 和模型 ID 都没填错。主要看对话是否正常返回、控制台里是否有对应的请求记录。如果准备把执行计划解释做成日常排障动作可以打开 Coding Plan 看看长期用量够不够Key 的管理统一在 控制台 API Keys 里操作。拿到 Key 后Codex 就能通过 TaoToken 读懂display_cursor的真实输出把 A-Rows 与 E-Rows 的偏差逐行列出来。你只需要在 SQL*Plus 里跑完 SQL把执行计划贴回去剩下的偏差定位交给它省掉在十几个节点里肉眼找异常值的时间。
