要让豆包准确理解sql慢查询的索引优化方向，提示词必须明确定义语句类型、执行瓶颈、原始sql，并聚焦where条件顺序、join字段索引、order by/limit覆盖三个维度，同时排除单列索引滥用和or条件误用等常见错误。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要让豆包准确理解SQL慢查询的索引优化方向，提示词必须明确暴露查询结构、驱动表、过滤条件、连接方式和排序分组行为，不能只说“太慢了请优化”。
先告诉豆包这是什么类型的SQL
第一步：在提示词开头用一句话定义语句类型，例如：“这是一条多表JOIN查询，主表是orders，通过user_id关联users表，再通过product_id关联products表”。
第二步：说明执行瓶颈现象，例如：“EXPLAIN显示orders表走了全表扫描，rows=85234，而users表用了idx_user_id索引，rows=1”。
使用豆包（火山引擎 Ark）生成图片或视频并保存本地。用户提及“豆包生图/图片/生视频/视频”、“Doubao”、“Seedance”、“火山引擎图片/视频”时触发。
第三步：直接给出原始SQL（不要省略WHERE、ORDER BY、GROUP BY等关键子句），确保豆包能解析出谓词下推路径和访问顺序。
强制它聚焦索引设计的三个核心维度
方法一：按WHERE条件列声明索引字段顺序
写成：“WHERE中出现的过滤字段依次是status、created_at、user_id，请分析这三个字段组合建索引时，哪个字段必须放最左，为什么？”
方法二：对JOIN字段单独点名
写成：“orders.user_id = users.id 是驱动表到被驱动表的等值连接条件，但users表上只有主键索引，没有单独的user_id索引——这会导致users表每次被扫描多少行？是否应该为users.user_id单独建索引？”
方法三：把ORDER BY和LIMIT也纳入索引考量
写成：“查询末尾有 ORDER BY created_at DESC LIMIT 20，当前索引(idx_status_created_at)中created_at是第二列，但status取值离散度很低（只有'paid'/'cancelled'两种），这种情况下该索引能否避免filesort？如果不能，应如何调整索引字段顺序或补充覆盖字段？”
用反例堵死常见错误思路
在提示词里插入一句：“注意：不要建议给每个WHERE字段都单独建单列索引，【MySQL在一次查询中通常只用一个索引】，重点分析复合索引的最左前缀匹配路径。”
再加一句：“如果SQL里有 OR 条件（如 WHERE a=1 OR b=2），不要默认推荐(a,b)联合索引——因为OR会让索引失效，此时应考虑UNION ALL拆解或函数索引（MySQL 8.0+）。”
