目标：将以下查询从8.2秒压到300毫秒内。表结构：SHOW CREATE TABLE device_info_new\G；数据分布：SELECT COUNT(*) FROM device_info_new WHERE state='0'；索引现状：SHOW INDEX FROM device_info_new；原始SQL：待提供。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
当你在MySQL中执行一条查询耗时超过5秒，而EXPLAIN显示type=ALL、rows=千万级、Extra里写着Using temporary; Using filesort时，说明已陷入典型慢查询困境，必须借助外部分析能力快速定位根因。
准备可被ChatGPT理解的上下文
把原始SQL复制进剪贴板，不要直接粘贴就提问。先手动整理三类信息：表结构（用SHOW CREATE TABLE device_info_new\G）、关键字段数据分布（SELECT COUNT(*) FROM device_info_new WHERE state='0'）、以及当前索引现状（SHOW INDEX FROM device_info_new）。
这一步漏掉任何一项，ChatGPT都可能建议建错索引——比如它不知道imei1列99%为空，却建议你给该字段单独建索引。
把这三段信息合并成一段文字，开头注明“目标：将以下查询从8.2秒压到300毫秒内”，再附上原始SQL。不要截图，不要PDF，纯文本。
向ChatGPT提交精准提示词
打开ChatGPT官网对话框，粘贴你刚整理好的上下文，然后追加一句：
“请分三步回答：①指出当前执行计划中最致命的3个问题；②给出可立即执行的索引创建语句（含表名和字段顺序）；③重写SQL，消除OR条件导致的索引失效，并说明为什么新写法能走索引。”
【必须限定输出结构】不加这句，它会泛泛而谈“可以考虑分区”“建议升级硬件”，完全偏离实操需求。
如果使用GPT-4o模型，响应时间通常在2～4秒；若用免费版GPT-3.5，可能需要补充追问“请只输出SQL语句，不要解释”才能拿到干净结果。
用于在用户想通过浏览器自动化与 Google Gemini 或 ChatGPT 交互时。触发短语包括“ask Gemini”“ask ChatGPT”“ask GPT”“让...”。
验证与执行优化方案
方法一：本地快速验证索引效果
在MySQL命令行中执行CREATE INDEX idx_d_state_sn_imei ON device_info_new (state, sn, imei1, imei2)；注意字段顺序必须和ChatGPT建议完全一致，否则联合索引无效。
方法二：跳过建索引，先测SQL改写效果
把ChatGPT返回的重写SQL粘贴执行，观察实际耗时。若仍超1秒，立刻回到第一步——说明你提供的表结构或数据量描述有误，比如把“production_log表1.2亿行”写成了“120万行”。
方法三：强制走索引对比（仅调试用）
在原始SQL末尾加上USE INDEX (idx_d_state_sn_imei)，运行后对比执行时间。若提速明显，证明索引方向正确；若无变化，说明WHERE条件中的OR逻辑仍未被拆解，需退回第二步重新提交提示词。
执行完任一方法后，用EXPLAIN FORMAT=TREE重跑SQL，确认output里不再出现"table_scan"字样。
