你是一名MySQL 8.0 DBA。请基于提供的执行计划、表结构及字段基数，严格按四部分输出：瓶颈定位、根本原因、立即生效方案、验证方式；禁用模糊表述，所有结论须由给定信息直接推导。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让deepseek一次性输出可落地的sql慢查询优化思路，避免反复修改提示词、反复生成、反复核对执行计划。核心是把数据库上下文、性能瓶颈特征和期望输出格式提前结构化喂给模型。第一步：明确告诉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或提前聚合”。
