你需提供完整SQL、对应EXPLAIN结果及SHOW CREATE TABLE输出，三者缺一不可；豆包仅凭SQL无法定位真实瓶颈，必须结合执行计划与表结构才能给出可落地的索引优化或SQL重写方案。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让豆包（Doubao）这类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或建表语句，豆包生成的提示词大概率无法定位真实瓶颈】
把原料塞进豆包提示词的固定骨架里
复制以下模板，把上一步抠出的三样原料分别填入【】标记处：
立即进入“豆包AI人工智官网入口”；
立即学习“豆包AI人工智能在线问答入口”；
使用豆包（火山引擎 Ark）生成图片或视频并保存本地。用户提及“豆包生图/图片/生视频/视频”、“Doubao”、“Seedance”、“火山引擎图片/视频”时触发。
你是一名有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缓存热点结果、或拆分为应用层多次查询。对比各方案实施成本与收益。”
方法三：新人带教型（教 junior 开发自己看懂慢查）
在模板末尾加一句：“请用通俗语言解释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或建表语句。
