你让 Claude 写一条统计订单的 SQL，语法能跑，上线后慢查询告警狂响——它压根没提该走哪个索引，也没提醒你 WHERE 条件会导致全表扫描。你回去追问「要不要索引」，它才补一句「可以考虑在 user_id 上建索引」，但缺少选择性、写入代价与是否覆盖的判断。
漏索引提示，是因为默认任务被理解成「写出能跑的语句」，而不是「写出可上线的查询方案」。把执行计划意识、表规模与现有索引列表写进提示词，才会稳定附带索引建议。
直接结论
每次请 Claude 写 SQL，都要求同时输出：SQL、预估访问路径、建议索引（含列顺序）、不建议建索引的理由、以及风险（写放大/排序文件）。提供现有索引与表行数，比事后追问有效得多。
具体做法
把表结构、现有索引、数据量级贴全；说明数据库类型与是否允许加索引。
你是熟悉{MySQL 8/PostgreSQL}的资深DBA。请根据需求写SQL，并强制附索引分析。
表结构与现有索引：
{粘贴}
数据量：订单表约{N}行，日增{…}
需求：{业务问题}
输出必须包含：
1) 最终SQL（可读、有别名）
2) 预期使用的索引与过滤顺序
3) 若需新建索引：给出CREATE语句、列顺序理由、对写入的影响
4) 若不应新建：说明原因（已有覆盖/低选择性等）
5) 可能的慢点与改写备选（如避免前导模糊匹配）
禁止只给SQL不给索引评论。
对生成结果用 EXPLAIN 核对，把真实计划贴回让它二次修订。
批量需求时要求它按「高频查询」优先提索引，避免为一次性报表乱建。
注意点
第一，低选择性列单独建索引收益差，提示词要求评估选择性。
第二，覆盖索引与普通索引要分清，别只丢一列名字。
第三，写多读少系统要显式权衡写入代价，不能默认「有查询就建」。
上线前把「索引变更」当成独立评审项：回滚方式、锁表风险、是否在线 DDL。Claude 可以起草变更说明，但执行窗口与监控指标必须由你确认。把慢查询日志片段一并喂给模型，比空谈优化更接近真实瓶颈。
可直接套用的完整提示词
角色：DBA + 数据分析工程师。 任务：SQL + 索引方案一体交付。 输入：DDL、现有索引、行数、慢查询/需求描述、DB引擎。 输出模板： 【SQL】 【EXPLAIN预期】 【索引建议】（CREATE/不建及理由） 【风险】 【验证步骤】（用什么SQL看执行计划、看什么指标） 约束：列名必须来自DDL；不确定处标假设；给出至少1个备选写法。
把「索引建议」写进 Definition of Done：没有索引评论的 SQL 视为未完成。对分析师同学，可要求 Claude 同时给「业务可读解释」与「DBA 可读建议」，减少翻译成本。若环境禁止随便建索引，就让它优先给改写方案（减少排序、避免函数包裹列、拆查询）。
线上验证时对比加索引前后的扫描行数与耗时，把结果回贴，模型下次会更贴合你的数据分布。缺少反馈的优化讨论，很容易停在教科书层。
对于报表类一次性 SQL，明确告诉 Claude「不建议为它建永久索引」，让它给临时策略（物化、限流、离峰跑）。索引建议要匹配生命周期。
当 EXPLAIN 显示类型为 ALL 时，把结果贴回，要求它给出「不改业务语义」的最小改动方案，避免为了索引牺牲正确性。