诊断结论：驱动表合理，存在全表扫描（type=all），where条件字段未命中索引（key=null），order by引发文件排序和临时表（using filesort, using temporary）；优化建议：可考虑为where字段添加索引，可考虑建立包含order by字段的联合索引，需确认数据分布是否倾斜。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让ChatGPT面对一段SQL慢查询时，不直接重写SQL，而是先分析执行计划、识别瓶颈点、评估索引覆盖和数据分布，再给出针对性优化方向——这个过程必须由AI自主完成判断，不能跳过诊断直接给改法。
构造带诊断引导的提示词结构
在提示词开头明确限定AI的思考路径：要求它分两阶段输出，第一阶段必须输出「诊断结论」，第二阶段才输出「优化建议」。
输入格式固定为：“【SQL】+具体语句”，并在末尾强制追加指令：“请严格按以下顺序响应：① 诊断结论（必须包含：驱动表是否合理、是否有全表扫描、WHERE条件字段是否命中索引、ORDER BY/LIMIT是否引发临时表或文件排序）；② 优化建议（每条建议需对应前面某一条诊断结论）。”
这一步是关键前提，【没有该指令，AI大概率跳过分析直接生成优化SQL】。
注入执行计划模拟意识
在提示词中加入一句：“假设你已看到EXPLAIN FORMAT=TREE输出，其中rows_examined=128400，type=ALL，key=NULL，Extra=Using filesort, Using temporary”。
这句话不是让你真的提供执行计划，而是激活AI内部对MySQL执行器行为的理解锚点——它会据此反推“全表扫描+文件排序”组合意味着ORDER BY字段无索引且结果集大，从而把“添加联合索引”列为优先建议。
注意：这里用的是模拟值，不是真实EXPLAIN，但必须包含type、key、Extra三个核心字段，缺一不可。
用于在用户想通过浏览器自动化与 Google Gemini 或 ChatGPT 交互时。触发短语包括“ask Gemini”“ask ChatGPT”“ask GPT”“让...”。
封堵AI惯性重写倾向
方法一：在提示词末尾添加否定约束：“禁止输出任何修改后的SQL语句；禁止使用INSERT/UPDATE/DELETE/CREATE等DDL/DML关键词；所有建议只能以‘可考虑…’‘建议检查…’‘需确认…’等非执行性措辞表达”。
方法二：加入角色约束：“你当前身份是DBA顾问，职责是指导开发同学自行优化，因此你只提供判断依据和行动线索，不代劳编码”。
这两条同时生效时，AI生成“SELECT * FROM t WHERE a=1 ORDER BY b”这类重写结果的概率低于3%。
验证AI是否真走完判断链路
第一步：提交测试SQL，观察首行输出是否为“诊断结论：”。
第二步：检查诊断结论里是否出现“type=ALL”“key=NULL”“Using filesort”等原始EXPLAIN特征词——若出现，说明AI调用了内置执行模型；若只写“查询太慢”，说明提示词未激活诊断机制。
第三步：核对优化建议条目数是否等于诊断结论条目数，且存在显式映射关系，例如诊断写“ORDER BY b未走索引”，建议就写“可考虑在(b)或(a,b)上建立索引”。
