豆包SQL慢查询优化提示词：真实场景实战指南
你问的这个问题非常实际——如何让豆包这样的AI助手真正帮你诊断生产环境中的慢SQL，而不是只会敷衍地说“加索引”“别用SELECT *”。我猜你经历过这种场景：凌晨三点，订单查询接口突然超时，DBA丢来一条执行耗时12.7秒的SQL及其EXPLAIN结果，你需要立刻写出能直接粘贴到豆包对话框的提示词，让它给出可落地的优化方案。下面这套方法我验证过多次，照着执行基本不会踩坑。
从真实慢查询日志提取三项核心要素
在MySQL慢查询日志（例如 /var/log/mysql/slow.log）中找到目标SQL，手动提取以下三项：
- 完整的SQL语句（包括换行和注释）
- 对应的EXPLAIN输出（重点分析
type、key、rows、Extra等字段） - 表结构片段（通过
SHOW CREATE TABLE user\G截取，关注索引定义和数据类型）
这三项缺一不可。如果只丢一条SQL给豆包，它会基于通用规则盲目猜测——这就像只告诉医生“我肚子疼”，医生无法判断是肠胃炎还是阑尾炎。附上EXPLAIN，它才能理解“为什么慢”；带上建表语句，它才能分析“为什么这个索引没被用上”。【缺少EXPLAIN或建表语句，豆包生成的提示词几乎无法精准定位瓶颈】
将三项要素填入豆包提示词的固定模板
直接复制下面的模板，将上一步提取的三项内容分别填入【】标记处：
你是一名具备5年MySQL调优经验的DBA。现在我有一条生产环境中的真实慢查询，需要你给出可立即验证的优化方案。请严格按照以下步骤执行：
1. 根据我提供的EXPLAIN分析执行计划，明确指出当前扫描方式（ALL/INDEX/RANGE等）、是否使用了索引、预估扫描行数、Extra中是否存在Using filesort或Using temporary等致命问题；
2. 结合表结构，评估现有索引是否合理，是否存在最左前缀失效、隐式类型转换、函数导致索引失效等情况；
3. 给出具体修改建议：包括是否需要新建联合索引（写出CREATE INDEX语句）、是否要重写WHERE条件（例如将YEAR(create_time)=2025改为create_time BETWEEN '2025-01-01' AND '2025-12-31'）、是否要拆分查询或添加LIMIT；
4. 最后提供优化后的完整SQL，并说明预期性能提升幅度（例如“预计从12.7秒降至0.3秒以内”）。
以下是原始信息：
【此处粘贴完整SQL语句】
EXPLAIN结果：
【此处粘贴EXPLAIN输出】
对应表结构：
【此处粘贴SHOW CREATE TABLE输出】
根据场景调整提示词的关键侧重点
上述模板是通用框架，但针对特定场景微调关键词能显著提升效果。
场景一：紧急救火型（运维已告警，需5分钟内响应）
在模板开头追加一句：“当前该SQL在用户订单查询接口中触发，QPS 87，平均响应时间12.7秒，已导致32%请求超时。请优先给出零代码改动的方案（如加索引、改hint），确保10分钟内可上线。”——这样豆包会意识到你急需止血方案，而不是长篇大论重构业务逻辑。
场景二：深度重构型（发版前做SQL健康体检）
将模板第3步改为：“除索引和SQL重写外，请评估是否适合改用物化视图、引入Redis缓存热点结果、或拆分为应用层多次查询。对比各方案的实施成本与收益。”——适合你在重构代码前借助豆包权衡各种方案的利弊。
场景三：新人带教型（教初级开发理解慢查询）
在模板末尾添加一句：“请用通俗语言解释EXPLAIN中key_len=5和type=range的具体含义，并举例说明为什么WHERE city = '杭州' AND age > 25 能用到(idx_city, idx_age)联合索引，但WHERE age > 25 AND city = '杭州' 却不能。”——豆包的解释比大多数同事更有耐心。
验证提示词有效性的两个硬性标准
将最终拼好的提示词提交给豆包后，其返回内容必须同时满足以下两点才算合格：
- ① 明确指出原SQL中导致全表扫描的列（例如“WHERE SUBSTRING(phone,1,3)='138'使idx_phone失效”）
- ② 给出的CREATE INDEX语句能在MySQL中直接执行（字段顺序、数据类型、ASC/DESC与实际需求一致）
只要有一个不满足，说明提示词缺少关键上下文——请回头检查EXPLAIN或建表语句是否遗漏。这一步不要嫌麻烦，否则后续调试更耗时。