新手必看：豆包SQL优化提问提示词如何说明表量与索引

要引导豆包输出精准的SQL优化方案，核心在于完整呈现“上下文信息”。数据规模、索引构成、执行环境——这些要素直接决定AI推荐的可执行性。若仅丢出一条孤立的查询语句，AI会基于“小样本”推理，其建议在几千行的小表上或许奏效，但放到千万级的生产环境，反而可能引发性能恶化。

那么，具体该如何向豆包组织输入信息？逐层拆解如下。

明确告知豆包表的数据量级

第一，直接说明行数，使用“约”“近”“超”这类词避免虚假精确。例如“用户表 user_info 约 850 万行”——这比模糊的“user_info 表很大”更具量化价值。豆包需要可度量的输入，而非定性描述。

第二，补充关键字段的分布特征。举例：“status 字段只有 3 个取值（0/1/2），但 create_time 跨度达 5 年，且近 3 个月的数据占总量的 72%。” 此类信息能帮助豆包判断是否更适合采用时间分区或函数索引来优化。

第三，若涉及多表关联，必须说明主从关系与连接基数。例如：“订单表 order_detail 关联主表 order_header，平均每个 order_id 对应 1.8 条明细记录。” 基数差异会大幅改变优化策略——一个主表对应数十条明细与仅对应一条明细，索引设计思路截然不同。

清晰描述现有索引结构

方法一：直接使用 SQL SHOW CREATE TABLE 输出片段（最佳实践）。复制粘贴实际执行结果中 KEY 部分，例如 KEY idx_status_ctime (status, create_time)、KEY uk_mobile (mobile) UNIQUE。这比口头表述“status 和 create_time 有联合索引”准确得多，因为字段顺序、索引类型等细节都会影响优化判断。

方法二：手动列举时按规范格式书写。写成“索引名（字段1, 字段2 ASC, 字段3 DESC）[类型]”，例如：
idx_user_type_level（user_type, level DESC）[B-tree]
uk_order_no（order_no）[唯一]
ft_title（title）[全文]

方法三：指出缺失但业务高频使用的组合。例如：“查询常常携带 WHERE category = ? AND is_deleted = 0 ORDER BY sort_order LIMIT 20，但当前没有任何索引覆盖这三个字段。” 这将直接引导豆包考虑是否需要创建覆盖索引。

将SQL与上下文一同提交给豆包

第一步，贴出待优化的原始SQL，保留真实表名与字段名，不要用 t1/t2 替代。豆包需要理解真实的业务语义才能判断优化方向。

第二步，说明执行频率与典型响应时间。例如：“该SQL每天执行 2.3 万次，P95 响应时间为 1420ms，高峰期常触发慢查询告警。” 这类信息能让豆包明确当前问题的严重程度与优化优先级。

第三步，附上 EXPLAIN 结果关键行。仅截取 type、key、rows、Extra 四列即可，例如：
type: ALL → key: NULL → rows: 3276841 → Extra: Using where; Using filesort

拥有这些信息后，豆包才能给出真正可落地的优化方案，而非空洞的“建议建索引”。