AI知见 · AI工具怎么选，3步帮你搞定

解决场景：接口越来越慢，知道是SQL的锅但不知道咋优化。本条提示词经AI知见编辑部实测通过（DeepSeek，2026-10-30），正文附完整可复制全文与使用说明。

DeepSeek SQL优化提示词：慢查询从执行计划到索引建议一条龙

提示词全文（复制即用）

你是数据库性能优化专家。我会给你一条慢SQL和它的执行计划，请按以下框架分析：

1. 【翻译执行计划】：用大白话说清数据库现在在干什么（全表扫了哪、索引用没用上、排序是不是落盘了）；
2. 【根因定位】：慢的根因是什么，按贡献度排序；
3. 【优化方案】：给出 2-3 个方案——索引调整 / SQL改写 / 业务侧改造，每个方案注明预期收益和实施成本；
4. 【验证方法】：改完后怎么验证效果（对比执行计划哪些字段）；
5. 【副作用预警】：新索引对写入的影响、改SQL对现有功能的影响。

表结构：【粘贴建表语句】
慢SQL：【粘贴SQL】
执行计划：【粘贴EXPLAIN结果】
数据量级：【表数据量、QPS】

怎么用（3步）

EXPLAIN你的慢SQL，把结果和执行计划一起贴给AI
优先实施"收益高成本低"的方案（通常是一条联合索引）
改完对比EXPLAIN的type和rows字段，把前后结果贴回给AI确认

真实输出示例

实测（订单列表查询3.2秒）：AI从EXPLAIN看出" Using filesort "且走了user_id索引但排序字段不在索引内，建议建(user_id, status, created_at)联合索引——执行时间降到0.04秒。一句话点破了我们两天没找到的根因。

这条提示词，用哪个工具跑？

DeepSeek（免费）、Claude（免费+付费）

不确定选哪个？3步帮我选工具按你的场景直接给答案 · 返回提示词库

常见问题

没有执行计划能分析吗？

能给出假设性建议，但准确性打对折。执行计划是优化的证据，养成"先EXPLAIN再提问"的习惯，AI的答案质量会天差地别。

加索引总是对的吗？

不是。索引加速读但拖慢写，还占空间。写多读少的表（日志表）加索引要谨慎——这也是为什么提示词要求AI给副作用预警。