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慢查询,同时给出可执行的索引创建语句——这不能靠简单提问实现,必须构造带上下文的结构化输入。
先从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末尾。缺少这一行,模型无法定位扫描方式缺陷。
打开你的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参数,防止锁表阻塞业务写入。