 获取执行计划：TaoToken 统一 Key 接入 AI 工具排查 SQL 慢查询)
1. 慢查询排查里为什么我坚持先看真实执行计划Oracle 里一条 SQL 突然变慢很多人的第一反应是打开 PL/SQL Developer 按 F5看那个「执行计划」窗口。但那个计划是估算出来的优化器在解析阶段给出的预估值跟 SQL 真正跑起来时用的计划可能完全不是一回事。绑定变量窥探、自适应游标共享、统计信息过期、执行环境差异任何一个因素都能让估算计划和真实计划分道扬镳。你盯着一个假的计划调索引调半天没效果问题就出在这里。dbms_xplan.display_cursor()解决的就是这个问题。它从 Shared Pool 的游标缓存里把 SQL 实际执行时用的计划捞出来带上A-Rows、A-Time、Buffers、Reads这些运行时统计让你看到每一步到底扫了多少行、花了多少时间、读了多少块。这是排查慢查询最硬的一手证据。但拿到执行计划只是第一步。一份ALLSTATS LAST的计划动辄几十行E-Rows和A-Rows差了几个数量级的地方在哪、哪一步A-Time占比最高、Buffers异常的是哪个操作靠人眼一行行对效率很低。我试过把执行计划直接丢给 AI 工具做解读让它帮我标出估算偏差最大的节点和耗时瓶颈再结合我的业务上下文给优化方向比纯手工快很多。这篇就讲怎么把dbms_xplan.display_cursor()的采集动作和 TaoToken 统一 Key 接入 AI 工具这条链路串起来做成一个可复用的排查流程。适合谁看日常要处理 Oracle 慢 SQL 的 DBA、后端开发以及已经在用 Cline、CC Switch 这类 AI 编码工具、想把数据库排查也接进同一套 Key 通道的人。你不需要是执行计划专家但得能连上数据库、能跑 SQL。2. 前置准备TaoToken 统一 Key 与工具接入TaoToken 在这里的角色是一个统一的 API 通道。你不需要为每个 AI 工具单独申请 Key、单独配计费而是用同一个 Key 走同一个入口Cline、CC Switch 这些工具都指向它。对 DBA 来说好处很直接排查 SQL 的时候顺手把执行计划贴给 AI不用在多个平台之间切换账号。先拿到 Key。打开官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册后在控制台里创建 API Key。控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content Key 管理页在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。API 的基础地址是 https://taotoken.net/api 注意这个地址不带 UTM 参数配置的时候直接写这个。Key 拿到后先别急着配工具用模型对话页面验证一下通道通不通https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。在里面随便问一句能正常返回就说明 Key 和通道没问题。这一步很重要后面工具报错的时候你能快速判断是 Key 的问题还是工具配置的问题。如果你主要用 Cline 做编码和排查长期高频调用建议看下 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 配置细节以文档为准。3. 可复制配置settings.json 与 config.toml 骨架不同工具的配置文件格式不一样。Cline 这类 VS Code 插件通常读settings.jsonCC Switch 这类命令行工具用config.toml。下面给两份骨架你把 Key 填进去就能用。3.1 Cline 的 settings.json 骨架Cline 的配置一般放在用户设置或工作区设置里。核心是把 API 提供方指向 TaoToken 的兼容入口模型名按你实际要用的填。{ cline.apiProvider: openai, cline.openAiApiKey: sk-你的TaoTokenKey, cline.openAiBaseUrl: https://taotoken.net/api, cline.openAiModelId: claude-sonnet-4-20250514, cline.enableAutoApprove: false, cline.requestTimeout: 120000 }几个点说明一下。openAiBaseUrl写https://taotoken.net/api不要带末尾斜杠也不要带 UTM 参数。openAiModelId按你账号里可用的模型填具体型号看模型对话页面或接入文档。requestTimeout给大一点执行计划文本长的时候响应会慢一些。3.2 CC Switch 的 config.toml 骨架CC Switch 用 TOML 格式结构大致如下[provider] name taotoken base_url https://taotoken.net/api api_key sk-你的TaoTokenKey model claude-sonnet-4-20250514 timeout 120 [behavior] stream true max_tokens 8192 temperature 0.2temperature调低一点排查场景要的是稳定解读不是发散创作。max_tokens给足执行计划加解读容易超。3.3 环境变量方式可选有些工具支持从环境变量读 Key这样配置文件里就不用写明文export TAOTOKEN_API_KEYsk-你的TaoTokenKey export TAOTOKEN_BASE_URLhttps://taotoken.net/api配好之后工具侧引用TAOTOKEN_API_KEY即可。生产机器上建议用这种方式避免 Key 落在配置文件里被误提交。4. 采集执行计划并交给 AI 解读的完整验证配置通了接下来走一遍真实流程。目标是把一条慢 SQL 的真实执行计划采出来贴给 AI拿到可读的瓶颈分析。4.1 开启运行时统计dbms_xplan.display_cursor()默认的TYPICAL格式只有估算值要看A-Rows、A-Time这些实际数据得先让 SQL 收集统计。两种方式选一种-- 方式一会话级开启 ALTER SESSION SET STATISTICS_LEVEL ALL;-- 方式二在 SQL 里加 hint只对这条语句生效 SELECT /* GATHER_PLAN_STATISTICS */ o.order_id, o.customer_id, o.amount FROM orders o WHERE o.status PENDING AND o.created_at SYSDATE - 7;方式一影响整个会话方式二只影响单条。排查单条慢 SQL 用方式二更干净。4.2 拿到 SQL_IDSQL 执行完从V$SQL里查它的SQL_IDSELECT sql_id, child_number, executions, elapsed_time/1000000 AS elapsed_sec FROM v$sql WHERE sql_text LIKE %orders o%status PENDING% AND sql_text NOT LIKE %v$sql% ORDER BY last_active_time DESC;elapsed_time单位是微秒除以 1000000 换成秒。child_number也要记下来有多个子游标的时候要指定否则返回的是全部子游标的计划。4.3 用 display_cursor 采集真实计划拿到sql_id和child_number后SELECT * FROM TABLE( DBMS_XPLAN.DISPLAY_CURSOR( sql_id 你的sql_id, child_number 0, format ALLSTATS LAST ) );ALLSTATS LAST等价于IOSTATS MEMSTATS LAST会输出每一步的实际行数、实际时间、逻辑读、物理读、内存使用。这是排查慢查询最有用的格式。如果你只想看估算和实际行数的对比TYPICAL ROWS BYTES COST也够用。输出大概长这样节选| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | | 0 | SELECT STATEMENT | | 1 | | 1523 |00:00:02.31 | 48210 | 1204 | | 1 | TABLE ACCESS BY INDEX ROWID | ORDERS | 1 | 200 | 1523 |00:00:02.28 | 48210 | 1204 | |* 2 | INDEX RANGE SCAN | IDX_ORD_ST | 1 | 200 | 1523 |00:00:00.85 | 1203 | 8 |这里E-Rows是 200A-Rows是 1523估算差了 7 倍多优化器低估了返回行数可能导致它选了不合适的连接方式或索引。A-Time显示总耗时 2.31 秒主要花在TABLE ACCESS BY INDEX ROWID上Buffers48210 说明回表读了很多块。这些就是 AI 解读要抓的重点。4.4 把计划交给 AI 解读把上面这段计划文本复制出来在 Cline 或 CC Switch 里贴给 AI配一句提示这是一条 Oracle SQL 的真实执行计划ALLSTATS LAST 格式。 请帮我 1. 找出 E-Rows 和 A-Rows 偏差最大的节点说明可能原因 2. 指出 A-Time 和 Buffers 占比最高的操作 3. 结合 statusPENDING 且 created_at 近 7 天的过滤条件给出索引或 SQL 改写建议。AI 会返回一份结构化的分析比如指出IDX_ORD_ST这个索引的选择性在statusPENDING下不够好建议建组合索引(status, created_at)或者提示回表次数过多可以考虑覆盖索引。你拿到这些方向再回数据库验证比盲调快得多。4.5 验证 AI 建议AI 给的建议不能直接信要验证。比如它建议建组合索引CREATE INDEX idx_ord_status_created ON orders(status, created_at);建完重新执行原 SQL再采一次执行计划对比A-Time和BuffersSELECT * FROM TABLE( DBMS_XPLAN.DISPLAY_CURSOR( sql_id 你的sql_id, child_number NULL, format ALLSTATS LAST ) );child_number传NULL会把所有子游标的计划都返回方便你看到新计划。对比前后Buffers从 48210 降到多少、A-Time从 2.31 秒降到多少用数据说话。5. 本篇常见错排查5.1 返回 SQL_ID not found 或计划为空最常见的原因是 SQL 已经不在 Shared Pool 里了。display_cursor读的是游标缓存SQL 被 aged out 或者实例重启过就查不到。确认方法SELECT COUNT(*) FROM v$sql WHERE sql_id 你的sql_id;返回 0 就说明缓存里没了得重新执行一次 SQL 再采。另外注意sql_id大小写V$SQL里存的是小写。5.2 只有估算值没有 A-Rows 和 A-Time说明采集时没开统计。STATISTICS_LEVEL是TYPICAL的时候ALLSTATS格式不会输出运行时数据。检查SHOW PARAMETER statistics_level;如果是TYPICAL要么ALTER SESSION SET STATISTICS_LEVEL ALL要么在 SQL 里加/* GATHER_PLAN_STATISTICS */然后重新执行再采。5.3 在 PL/SQL Developer 里用 null 参数拿不到计划dbms_xplan.display_cursor(null, null, advanced)这种写法依赖「当前会话最后一条 SQL」只在 SQL*Plus 里可靠。PL/SQL Developer 执行完你的 SQL 后还会跑自己的后台语句最后一条 SQL 早就不是你的了。解决办法是显式传sql_id别依赖 null 默认值。5.4 AI 工具报 401 或连接失败先回模型对话页面确认 Key 本身能用。如果那边正常问题在工具配置检查base_url是不是写成了https://taotoken.net/api不要带 UTM、不要带末尾斜杠Key 有没有多余空格模型名是不是账号里可用的。Cline 的配置改完要重启窗口才生效。5.5 执行计划太长AI 截断或答非所问ALLSTATS LAST在复杂 SQL 上可能上百行。两个办法一是只贴关键部分把Id、Operation、Name、E-Rows、A-Rows、A-Time、Buffers这几列保留其他列删掉二是分段贴先贴主计划再贴有疑问的子树。提示里明确告诉 AI「这是节选完整计划还有 N 行」避免它基于不完整信息下结论。6. 把这条链路固化成日常排查动作整套流程跑通后我把它压成了几个固定动作慢 SQL 出现先加GATHER_PLAN_STATISTICS重跑一次从V$SQL拿sql_id用ALLSTATS LAST采真实计划贴给 AI 要瓶颈分析按建议改索引或 SQL再采一次对比A-Time和Buffers。每一步都有明确的输入输出不靠感觉。工具侧Cline 和 CC Switch 共用同一个 TaoToken Key配置一次到处能用。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content Key 在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 管理。如果你还在用别的 AI 工具把base_url指向https://taotoken.net/api、Key 填同一个就能接进同一套通道不用重复申请。最后提醒一句AI 解读执行计划是加速器不是替代品。它帮你快速定位可疑节点但索引该不该建、SQL 该怎么改还得结合表数据量、写入频率、业务语义来判断。把 AI 的输出当成一份「重点检查清单」而不是最终答案。
【Oracle】用 dbms_xplan.display_cursor() 获取执行计划：TaoToken 统一 Key 接入 AI 工具排查 SQL 慢查询
1. 慢查询排查里为什么我坚持先看真实执行计划Oracle 里一条 SQL 突然变慢很多人的第一反应是打开 PL/SQL Developer 按 F5看那个「执行计划」窗口。但那个计划是估算出来的优化器在解析阶段给出的预估值跟 SQL 真正跑起来时用的计划可能完全不是一回事。绑定变量窥探、自适应游标共享、统计信息过期、执行环境差异任何一个因素都能让估算计划和真实计划分道扬镳。你盯着一个假的计划调索引调半天没效果问题就出在这里。dbms_xplan.display_cursor()解决的就是这个问题。它从 Shared Pool 的游标缓存里把 SQL 实际执行时用的计划捞出来带上A-Rows、A-Time、Buffers、Reads这些运行时统计让你看到每一步到底扫了多少行、花了多少时间、读了多少块。这是排查慢查询最硬的一手证据。但拿到执行计划只是第一步。一份ALLSTATS LAST的计划动辄几十行E-Rows和A-Rows差了几个数量级的地方在哪、哪一步A-Time占比最高、Buffers异常的是哪个操作靠人眼一行行对效率很低。我试过把执行计划直接丢给 AI 工具做解读让它帮我标出估算偏差最大的节点和耗时瓶颈再结合我的业务上下文给优化方向比纯手工快很多。这篇就讲怎么把dbms_xplan.display_cursor()的采集动作和 TaoToken 统一 Key 接入 AI 工具这条链路串起来做成一个可复用的排查流程。适合谁看日常要处理 Oracle 慢 SQL 的 DBA、后端开发以及已经在用 Cline、CC Switch 这类 AI 编码工具、想把数据库排查也接进同一套 Key 通道的人。你不需要是执行计划专家但得能连上数据库、能跑 SQL。2. 前置准备TaoToken 统一 Key 与工具接入TaoToken 在这里的角色是一个统一的 API 通道。你不需要为每个 AI 工具单独申请 Key、单独配计费而是用同一个 Key 走同一个入口Cline、CC Switch 这些工具都指向它。对 DBA 来说好处很直接排查 SQL 的时候顺手把执行计划贴给 AI不用在多个平台之间切换账号。先拿到 Key。打开官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册后在控制台里创建 API Key。控制台地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content Key 管理页在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。API 的基础地址是 https://taotoken.net/api 注意这个地址不带 UTM 参数配置的时候直接写这个。Key 拿到后先别急着配工具用模型对话页面验证一下通道通不通https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。在里面随便问一句能正常返回就说明 Key 和通道没问题。这一步很重要后面工具报错的时候你能快速判断是 Key 的问题还是工具配置的问题。如果你主要用 Cline 做编码和排查长期高频调用建议看下 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 配置细节以文档为准。3. 可复制配置settings.json 与 config.toml 骨架不同工具的配置文件格式不一样。Cline 这类 VS Code 插件通常读settings.jsonCC Switch 这类命令行工具用config.toml。下面给两份骨架你把 Key 填进去就能用。3.1 Cline 的 settings.json 骨架Cline 的配置一般放在用户设置或工作区设置里。核心是把 API 提供方指向 TaoToken 的兼容入口模型名按你实际要用的填。{ cline.apiProvider: openai, cline.openAiApiKey: sk-你的TaoTokenKey, cline.openAiBaseUrl: https://taotoken.net/api, cline.openAiModelId: claude-sonnet-4-20250514, cline.enableAutoApprove: false, cline.requestTimeout: 120000 }几个点说明一下。openAiBaseUrl写https://taotoken.net/api不要带末尾斜杠也不要带 UTM 参数。openAiModelId按你账号里可用的模型填具体型号看模型对话页面或接入文档。requestTimeout给大一点执行计划文本长的时候响应会慢一些。3.2 CC Switch 的 config.toml 骨架CC Switch 用 TOML 格式结构大致如下[provider] name taotoken base_url https://taotoken.net/api api_key sk-你的TaoTokenKey model claude-sonnet-4-20250514 timeout 120 [behavior] stream true max_tokens 8192 temperature 0.2temperature调低一点排查场景要的是稳定解读不是发散创作。max_tokens给足执行计划加解读容易超。3.3 环境变量方式可选有些工具支持从环境变量读 Key这样配置文件里就不用写明文export TAOTOKEN_API_KEYsk-你的TaoTokenKey export TAOTOKEN_BASE_URLhttps://taotoken.net/api配好之后工具侧引用TAOTOKEN_API_KEY即可。生产机器上建议用这种方式避免 Key 落在配置文件里被误提交。4. 采集执行计划并交给 AI 解读的完整验证配置通了接下来走一遍真实流程。目标是把一条慢 SQL 的真实执行计划采出来贴给 AI拿到可读的瓶颈分析。4.1 开启运行时统计dbms_xplan.display_cursor()默认的TYPICAL格式只有估算值要看A-Rows、A-Time这些实际数据得先让 SQL 收集统计。两种方式选一种-- 方式一会话级开启 ALTER SESSION SET STATISTICS_LEVEL ALL;-- 方式二在 SQL 里加 hint只对这条语句生效 SELECT /* GATHER_PLAN_STATISTICS */ o.order_id, o.customer_id, o.amount FROM orders o WHERE o.status PENDING AND o.created_at SYSDATE - 7;方式一影响整个会话方式二只影响单条。排查单条慢 SQL 用方式二更干净。4.2 拿到 SQL_IDSQL 执行完从V$SQL里查它的SQL_IDSELECT sql_id, child_number, executions, elapsed_time/1000000 AS elapsed_sec FROM v$sql WHERE sql_text LIKE %orders o%status PENDING% AND sql_text NOT LIKE %v$sql% ORDER BY last_active_time DESC;elapsed_time单位是微秒除以 1000000 换成秒。child_number也要记下来有多个子游标的时候要指定否则返回的是全部子游标的计划。4.3 用 display_cursor 采集真实计划拿到sql_id和child_number后SELECT * FROM TABLE( DBMS_XPLAN.DISPLAY_CURSOR( sql_id 你的sql_id, child_number 0, format ALLSTATS LAST ) );ALLSTATS LAST等价于IOSTATS MEMSTATS LAST会输出每一步的实际行数、实际时间、逻辑读、物理读、内存使用。这是排查慢查询最有用的格式。如果你只想看估算和实际行数的对比TYPICAL ROWS BYTES COST也够用。输出大概长这样节选| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | | 0 | SELECT STATEMENT | | 1 | | 1523 |00:00:02.31 | 48210 | 1204 | | 1 | TABLE ACCESS BY INDEX ROWID | ORDERS | 1 | 200 | 1523 |00:00:02.28 | 48210 | 1204 | |* 2 | INDEX RANGE SCAN | IDX_ORD_ST | 1 | 200 | 1523 |00:00:00.85 | 1203 | 8 |这里E-Rows是 200A-Rows是 1523估算差了 7 倍多优化器低估了返回行数可能导致它选了不合适的连接方式或索引。A-Time显示总耗时 2.31 秒主要花在TABLE ACCESS BY INDEX ROWID上Buffers48210 说明回表读了很多块。这些就是 AI 解读要抓的重点。4.4 把计划交给 AI 解读把上面这段计划文本复制出来在 Cline 或 CC Switch 里贴给 AI配一句提示这是一条 Oracle SQL 的真实执行计划ALLSTATS LAST 格式。 请帮我 1. 找出 E-Rows 和 A-Rows 偏差最大的节点说明可能原因 2. 指出 A-Time 和 Buffers 占比最高的操作 3. 结合 statusPENDING 且 created_at 近 7 天的过滤条件给出索引或 SQL 改写建议。AI 会返回一份结构化的分析比如指出IDX_ORD_ST这个索引的选择性在statusPENDING下不够好建议建组合索引(status, created_at)或者提示回表次数过多可以考虑覆盖索引。你拿到这些方向再回数据库验证比盲调快得多。4.5 验证 AI 建议AI 给的建议不能直接信要验证。比如它建议建组合索引CREATE INDEX idx_ord_status_created ON orders(status, created_at);建完重新执行原 SQL再采一次执行计划对比A-Time和BuffersSELECT * FROM TABLE( DBMS_XPLAN.DISPLAY_CURSOR( sql_id 你的sql_id, child_number NULL, format ALLSTATS LAST ) );child_number传NULL会把所有子游标的计划都返回方便你看到新计划。对比前后Buffers从 48210 降到多少、A-Time从 2.31 秒降到多少用数据说话。5. 本篇常见错排查5.1 返回 SQL_ID not found 或计划为空最常见的原因是 SQL 已经不在 Shared Pool 里了。display_cursor读的是游标缓存SQL 被 aged out 或者实例重启过就查不到。确认方法SELECT COUNT(*) FROM v$sql WHERE sql_id 你的sql_id;返回 0 就说明缓存里没了得重新执行一次 SQL 再采。另外注意sql_id大小写V$SQL里存的是小写。5.2 只有估算值没有 A-Rows 和 A-Time说明采集时没开统计。STATISTICS_LEVEL是TYPICAL的时候ALLSTATS格式不会输出运行时数据。检查SHOW PARAMETER statistics_level;如果是TYPICAL要么ALTER SESSION SET STATISTICS_LEVEL ALL要么在 SQL 里加/* GATHER_PLAN_STATISTICS */然后重新执行再采。5.3 在 PL/SQL Developer 里用 null 参数拿不到计划dbms_xplan.display_cursor(null, null, advanced)这种写法依赖「当前会话最后一条 SQL」只在 SQL*Plus 里可靠。PL/SQL Developer 执行完你的 SQL 后还会跑自己的后台语句最后一条 SQL 早就不是你的了。解决办法是显式传sql_id别依赖 null 默认值。5.4 AI 工具报 401 或连接失败先回模型对话页面确认 Key 本身能用。如果那边正常问题在工具配置检查base_url是不是写成了https://taotoken.net/api不要带 UTM、不要带末尾斜杠Key 有没有多余空格模型名是不是账号里可用的。Cline 的配置改完要重启窗口才生效。5.5 执行计划太长AI 截断或答非所问ALLSTATS LAST在复杂 SQL 上可能上百行。两个办法一是只贴关键部分把Id、Operation、Name、E-Rows、A-Rows、A-Time、Buffers这几列保留其他列删掉二是分段贴先贴主计划再贴有疑问的子树。提示里明确告诉 AI「这是节选完整计划还有 N 行」避免它基于不完整信息下结论。6. 把这条链路固化成日常排查动作整套流程跑通后我把它压成了几个固定动作慢 SQL 出现先加GATHER_PLAN_STATISTICS重跑一次从V$SQL拿sql_id用ALLSTATS LAST采真实计划贴给 AI 要瓶颈分析按建议改索引或 SQL再采一次对比A-Time和Buffers。每一步都有明确的输入输出不靠感觉。工具侧Cline 和 CC Switch 共用同一个 TaoToken Key配置一次到处能用。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content Key 在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 管理。如果你还在用别的 AI 工具把base_url指向https://taotoken.net/api、Key 填同一个就能接进同一套通道不用重复申请。最后提醒一句AI 解读执行计划是加速器不是替代品。它帮你快速定位可疑节点但索引该不该建、SQL 该怎么改还得结合表数据量、写入频率、业务语义来判断。把 AI 的输出当成一份「重点检查清单」而不是最终答案。
