让大模型读懂执行计划：AI 驱动 SQL 优化的完整实战（附提示词模板）

一个团队的慢 SQL 积压量，通常与 DBA 的人数成反比。典型的分工困境是：业务开发看得懂业务但读不深执行计划，DBA 读得懂计划但不了解业务演进，慢查询治理在两个团队之间反复踢皮球。大模型改变了这件事的前提——EXPLAIN 输出是结构化文本，建表语句是结构化文本，优化专家的决策清单也可以写成结构化指令，这三者拼在一起，恰好是大模型最擅长的「读文档、做诊断」任务。这篇实战把整条链路拆开：上下文怎么采集、提示词怎么写、AI 建议怎么验证，最后落到人在环的落地纪律。

为什么大模型能做 SQL 优化：把专家的决策清单工程化

资深工程师优化一条慢 SQL 的动作是固定的：先读 SHOW CREATE TABLE 摸清索引底子，再读执行计划定位访问路径与瓶颈算子，结合表行数与数据分布判断成本是否失真，最后在「补索引」「改写 SQL」「修统计信息」三个选项里做权衡。这个流程的输入输出全部结构化，判断规则大部分可以显式枚举——最左前缀、等值在前范围在后、覆盖索引免回表、区分度高的列放前面、索引数量克制以控制写放大。把这些规则连同原始材料一起交给大模型，它扮演的就是一个不知疲倦、随时在线的初级优化顾问，而人负责审核与拍板。

实操：从慢日志到索引建议的完整链路

第一步，采集：圈定值得优化的目标。 别拿着单条偶发慢查询就开搞，先用聚合视图找出影响面最大的语句：

sql

-- 打开慢日志并降低阈值，圈定优化目标；log_slow_extra 补充更多扫描信息（8.0.14+）
SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 1;
SET GLOBAL log_slow_extra = ON;

-- 从性能视图拿 Top 慢语句摘要，按总耗时排序，优先治理影响面大的
SELECT DIGEST_TEXT, COUNT_STAR, SUM_TIMER_WAIT / 1e12 AS total_wait_sec
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;

采集阶段还要给目标分级：偶发超时与高频慢查询的治理优先级完全不同，前者记录待观察，后者立即进入优化队列，避免把精力花在没人受影响的 SQL 上。分级标准就用上表的 COUNT_STAR 与总耗时两个维度，一行代码的判断换来十倍的精力聚焦。

第二步，组装输入：给模型喂「三件套」。 建表语句（含索引）、树形执行计划、真实执行数据，缺一不可：

sql

-- 采集三件套：建表语句、树形执行计划、真实执行数据
SHOW CREATE TABLE order_info\G

EXPLAIN FORMAT = TREE
SELECT id, order_no, amount FROM order_info
WHERE user_id = 10086 AND status = 1
ORDER BY create_time DESC LIMIT 20;

-- EXPLAIN ANALYZE 提供实际行数与耗时，是模型判断预估偏差的关键输入
EXPLAIN ANALYZE
SELECT id, order_no, amount FROM order_info
WHERE user_id = 10086 AND status = 1
ORDER BY create_time DESC LIMIT 20;

区分度数据可以一条 SQL 拿齐：用 COUNT(*) 与 COUNT(DISTINCT 列) 的比值描述各列的选择性，连同现有索引一起写进提示词。模型没有这份材料时，会默认所有列都「值得建索引」；有了它，gender 这类低区分度列会被自动劝退，建议质量立上一个台阶。

第三步，用提示词模板约束输出。 模板的价值在于把「给建议」变成「给可验证的方案」：

text

角色：你是资深 MySQL DBA，负责优化 MySQL 8.0 上的慢 SQL。
输入：①目标 SQL；②SHOW CREATE TABLE 完整输出；③表行数与关键列区分度说明；④EXPLAIN FORMAT=TREE 与 EXPLAIN ANALYZE 输出；⑤调用频率与超时预算。
任务：
1. 逐算子解读执行计划，指出实际行数与预估行数偏差最大的环节；
2. 判断根因：索引缺失 / 索引失效 / 统计信息失真 / SQL 写法问题，多因并存时按影响排序；
3. 给出最多 2 条候选方案：每条包含完整可执行的 DDL 或改写后的 SQL、预期收益、风险（写放大、空间、兼容性）；
4. 明确验证方法：给出优化前后应执行的 EXPLAIN ANALYZE 与对比指标。
约束：不要虚构不存在的语法、hint 或系统变量；所有建议必须兼容 MySQL 8.0；禁止输出任何数据变更类 DML。
输出：JSON，字段为 root_causes、suggestions（type/sql/expected_gain/risk）、verification_steps。

第四步，回归验证：让证据说话。 每条建议落地前跑同一套验证动作：

sql

-- 建议落地前的固定动作：EXPLAIN ANALYZE 前后对比实际耗时与扫描行数
EXPLAIN ANALYZE
SELECT id, order_no, amount FROM order_info
WHERE user_id = 10086 AND status = 1
ORDER BY create_time DESC LIMIT 20;

-- 顺手检查冗余与闲置索引：新索引要算上写放大这笔账
SELECT * FROM sys.schema_redundant_indexes WHERE table_name = 'order_info';
SELECT * FROM sys.schema_unused_indexes WHERE object_name = 'order_info';

人在环：AI 建议上线前必须过的三道闸

第一道是事实闸：AI 会一本正经地编造不存在的 hint 与系统变量，或把 8.0 专属特性用到 5.7 库上，语法与特性要逐条对照官方文档核实。第二道是成本闸：模型天然倾向「加索引解决问题」，但每个新索引都在给写入链路加税，用 sys 的冗余与闲置索引视图守住底线，能靠改写 SQL 解决的优先改写。第三道是灰度闸：先在预发或从库验证，低峰窗口执行变更，变更前留好回滚脚本——AI 给出的是建议，执行权永远留在人手里。

让优化能力随时间复利，靠的是案例库沉淀。每次优化落地后，把「原始 SQL、执行计划、AI 建议、实际验证结果」四件套存档，定期挑典型案例转成提示词里的 few-shot 示例——同类问题第二次出现时，模型会直接参照历史解法，输出稳定性显著提升。日积月累，团队就多了一份会自我生长的优化知识库，这也是 AI 流程区别于一次性脚本的根本价值。

避坑总结

脱敏之后再投喂。 只给 DDL、执行计划与统计摘要即可，模型不需要真实行数据也能完成优化判断；表注释、字段名里带业务敏感语义的要先处理，外部模型调用尤其要过合规审查。
上下文给足，否则建议必然跑偏。 缺了表行数与列区分度，模型会给出「理论正确、实际无效」的索引建议；缺了调用频率，它分不清该为低频报表建重索引还是该改写应用逻辑。
每条建议都必须回归验证。 EXPLAIN ANALYZE 前后对比是唯一可信证据，实测与预期偏差大时优先怀疑数据分布假设错了，而不是急着怀疑数据库。
警惕索引冲动与幻觉。 用 sys.schema_redundant_indexes、sys.schema_unused_indexes 做加索引前的成本核算；对模型输出的任何语法与参数，先查文档再执行。
把「生成」与「执行」的权限隔离。 AI 工具链只授只读账号与建议输出，DDL 执行走人工变更平台，权限上保证模型永远无法直接改动生产库。

写在最后

SQL 优化是一门「读得懂数据库意图」的手艺，大模型把这门手艺的门槛降到了复制粘贴级别：采集三件套、套用提示词模板、拿回结构化建议，再用 EXPLAIN ANALYZE 完成闭环验证。日常遇到拿不准的慢 SQL，可以按本文模板跑一遍；也欢迎使用本站 MySQL 领域内置的免费 SQL AI 优化工具，粘贴 SQL 与建表语句即可自动生成执行计划解读与索引建议，再按本文的验证流程回归落地，让每一次优化都有证据背书。

免责声明

本工具与文章内容仅用于学习测试场景，优化建议仅供参考，请勿直接用于生产环境，由此产生的风险自行承担。

让大模型读懂执行计划：AI 驱动 SQL 优化的完整实战（附提示词模板） ​

为什么大模型能做 SQL 优化：把专家的决策清单工程化 ​

实操：从慢日志到索引建议的完整链路 ​

人在环：AI 建议上线前必须过的三道闸 ​

避坑总结 ​

写在最后 ​