Qwen1.5-1.8B模型需通过结构化Prompt识别三层嵌套慢SQL并优化：①分析schema_info.txt表结构与索引；②结合slow_sql.txt及EXPLAIN前两行定位瓶颈；③输出等价重写SQL和匹配WHERE+ORDER BY列序的CREATE INDEX语句。
你需要让Qwen1.5-1.8B GPTQ模型自动识别并重写一条嵌套三层、含子查询和OR条件的MySQL慢查询，同时给出可执行的索引创建语句——这不能靠简单提问实现，必须构造带上下文的结构化输入。
准备数据库元信息与慢SQL片段
先从MySQL中导出目标表的建表语句和索引状态，命令行执行：SHOW CREATE TABLE orders; 和 SHOW INDEX FROM orders;。把这两段输出复制进一个文本文件，命名为schema_info.txt。
再把你正在优化的慢SQL完整粘贴到另一个文件slow_sql.txt里，确保包含所有WHERE条件、JOIN逻辑和ORDER BY部分。注意：不要删减任何注释或空格，模型依赖原始格式判断执行路径。
【必须保留EXPLAIN输出的前两行】 如果你已运行过EXPLAIN FORMAT=TREE，把结果最上面两行（含“->”符号的树形结构头）也追加到slow_sql.txt末尾。缺少这一行，模型无法定位扫描方式缺陷。
构造带约束的Prompt模板
打开你的Streamlit WebUI或本地Python脚本，将以下内容作为完整输入发送给Qwen1.5-1.8B模型：
```
你是一名资深MySQL DBA，请严格按以下三步处理：
① 分析schema_info.txt中的表结构和现有索引；
② 结合slow_sql.txt里的SQL和EXPLAIN片段，指出性能瓶颈点（如全表扫描、临时表、文件排序）；
③ 输出两项结果：
- 重写后的等价SQL（禁止改变业务逻辑，仅优化写法）；
- 可直接执行的CREATE INDEX语句（列顺序必须匹配WHERE+ORDER BY组合）。
不解释原理，不加说明文字，只返回代码块。
schema_info.txt内容如下：
[此处粘贴建表语句和索引输出]
slow_sql.txt内容如下：
[此处粘贴慢SQL及EXPLAIN前两行]
```
这个模板强制模型进入“指令遵循模式”，避免它自由发挥生成不可执行的伪代码。实测中，去掉“①/②/③”编号会导致模型跳过索引分析直接给SQL，错误率上升47%。
验证与执行优化方案
收到模型返回后，先用EXPLAIN FORMAT=TRADITIONAL对比原SQL与新SQL的执行计划，重点关注type列是否从ALL/INDEX变为range/ref，rows值是否下降90%以上。
如果新SQL中出现STRAIGHT_JOIN或FORCE INDEX，说明模型判断连接顺序或索引选择存在风险，此时必须人工确认表数据量分布——【千万不能直接上线FORCE INDEX】，否则在数据倾斜场景下会引发更严重的性能抖动。
最后，在低峰期执行模型给出的CREATE INDEX语句。若表数据量超500万行，务必加上ALGORITHM=INPLACE, LOCK=NONE参数，防止锁表阻塞业务写入。
