SQL慢查询优化思路提示词：DeepSeek减少改稿技巧

第一步：明确告诉DeepSeek你用的是什么数据库

在提示词开头直接亮明数据库类型和版本，比如“你是一名MySQL 8.0 DBA”或“你正在分析PostgreSQL 15的执行计划”。别小看这一步——不写清楚，DeepSeek很可能按通用SQL逻辑推理，给你推荐索引时却忽略MySQL不支持函数索引前缀长度限制、或PostgreSQL里BRIN索引的适用场景等关键约束。一步漏掉，后续所有优化建议都可能脱离实际执行环境，白忙一场。

第二步：粘贴真实执行计划，不是SQL语句本身

把EXPLAIN ANALYZE（PostgreSQL）或EXPLAIN FORMAT=TREE / EXPLAIN FORMAT=JSON（MySQL 8.0+）的完整输出结果直接扔进提示词，而不是只丢一条SELECT语句。为什么？因为慢的本质往往藏在“Rows Removed by Filter”“Actual Total Time”“Buffers”这些字段里——光看SQL根本看不出Nested Loop是否失控、是否大量回表、是否触发了临时文件排序。

【必须粘贴带actual耗时和行数的执行计划，不能只给SQL】

第三步：限定输出结构，禁用模糊描述

用明确指令框住回复格式，例如：

请严格按以下四部分输出，每部分用中文标题加粗，不加编号，不解释原理，不提“可以考虑”“建议尝试”这类弱结论：

① 瓶颈定位：用一句话指出最耗时的节点（如“Index Scan on orders使用idx_user_id扫描127万行，但只返回83行，过滤率0.006%”）；

② 根本原因：说明为什么慢（如“索引idx_user_id未包含status字段，导致需回表判断WHERE status='paid'，引发127万次随机IO”）；

③ 立即生效方案：给出可直接执行的SQL（如“CREATE INDEX CONCURRENTLY idx_user_status ON orders(user_id, status) WHERE status IS NOT NULL;”）；

④ 验证方式：写清验证命令和预期结果（如“再次EXPLAIN ANALYZE，确认Filter条件消失，且Rows Removed by Filter=0”）。

没有这个结构约束，DeepSeek容易堆砌“加索引”“改写JOIN”“用覆盖索引”这些教科书式泛泛而谈，落地性大打折扣。

第四步：附上表结构关键信息

提供CREATE TABLE语句中与查询字段相关的部分，重点包括：主键、现有索引（可以通过SHOW CREATE TABLE xxx获取）、字段数据分布（比如user_id有80万不同值，status只有3个枚举值）。如果status字段99%是'pending'，那为它单独建索引就是无效操作——DeepSeek需要这个基数信息才能判断选择性。

方法一：直接粘贴SHOW INDEX FROM table_name和SELECT COUNT(DISTINCT status), COUNT(*) FROM table_name的结果；

方法二：用自然语言浓缩，例如“orders表共2100万行，user_id离散度高，status仅有pending/paid/cancel三种值，其中pending占92%”。

【不提供字段基数，模型无法判断索引是否值得建】

第五步：禁用“可能”“也许”“一般建议”类表达

在提示词末尾加一句硬性要求：“所有结论必须基于所给执行计划和表结构推导，禁止出现‘可能’‘大概’‘通常’‘建议评估’等不确定表述；若无法确定原因，请写‘执行计划中缺少XXX信息，无法定位’。”

这一招能强制模型放弃安全废话，倒逼它聚焦已知事实做因果链推理。比如看到Bitmap Heap Scan后Rows=1000但Actual Loops=500，就该直接指出“位图扫描被重复执行500次，说明外层嵌套循环驱动了500个不同user_id值，应改为HASH JOIN或提前聚合”。说“可能”的时候，往往就是没抓住根因。

来源：互联网