SQL慢查询优化提示词：索引方向的关键写法

要让豆包准确理解一条SQL慢查询到底该往哪个方向建索引，提示词不能只丢一句“太慢了请优化”就完事。你得把表结构、驱动表、过滤条件、连接方式甚至排序分组行为都摊开给它看。说白了，提示词必须让豆包一眼就能看清：**这是哪种类型的SQL、瓶颈出在哪、原始SQL长什么样**，然后重点聚焦WHERE条件顺序、JOIN字段索引、ORDER BY与LIMIT覆盖这三个维度，同时主动堵死单列索引滥用和OR条件误用这类常见坑。

换句话说，你给的上下文越接近DBA手边的真实场景，豆包给出的建议就越有实战价值。

先告诉豆包这是什么类型的SQL

第一步：在提示词开头用一句话把语句类型定死。比如：“这是一条多表JOIN查询，主表是orders，通过user_id关联users表，再通过product_id关联products表。” 别含糊。

第二步：把执行瓶颈的现象摆出来。比如：“EXPLAIN显示orders表走了全表扫描，rows=85234，而users表用了idx_user_id索引，rows=1。” 数据是最好的诊断线索。

第三步：直接贴原始SQL，别删WHERE、ORDER BY、GROUP BY、LIMIT这些关键子句。豆包需要靠它们推断谓词下推路径和访问顺序。

强制它聚焦索引设计的三个核心维度

方法一：按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+）。” 提前把雷排掉，豆包就不会给你那些看着对但实际上跑不动的方案。

来源：互联网