Qwen3-VL需结合带语义注释的数据库结构快照、显式表关系或样本数据、完整业务约束，再经时间函数版本、字段别名唯一性、LIMIT位置三重校验，才能生成准确SQL。
你想让Qwen3-VL直接听懂“上个月华东区复购用户里客单价超500元的前5名”，然后生成不出错的SQL，而不是反复调试字段名、JOIN条件或时间函数——这需要模型真正“看见”你的数据库结构，而不仅是靠关键词猜。
准备数据库结构快照
第一步：用mysqldump导出表结构（不含数据）到schema.sql文件：
mysqldump -u root -p --no-data ai_test_db > schema.sql
第二步：打开schema.sql，删掉所有CREATE DATABASE和USE语句，只保留CREATE TABLE块；每张表开头加一行注释，例如// users表：存储注册用户基本信息，主键id，外键被orders.user_id引用。这一步不能跳过，Qwen3-VL依赖这些语义注释建立“数据地图”，否则它会把user_id当成users表的字段而非关联键。
第三步：将清理后的schema.sql内容整体复制，作为系统提示词（system prompt）的一部分喂给Qwen3-VL。模型必须同时看到问题 + 结构描述 + 字段注释，三者缺一不可。
构造带上下文的查询提示
方法一：显式声明表关系
在自然语言问题前插入一段结构说明：“已知orders表中user_id字段关联users表的id字段；payment表中order_id字段关联orders表的order_id字段”。这能强制模型优先走正确JOIN路径，避免生成SELECT * FROM users, orders WHERE users.id = orders.user_id这类笛卡尔积风险语句。
方法二：嵌入样本数据行
在schema描述后追加两行真实样本（每表一行），格式为：users示例：(1, '张三', 28, 'zhangsan@email.com', '2025-03-12 10:22:33')。模型看到email字段是VARCHAR(150)，就不会误判为TEXT类型而用LENGTH()函数替代LIKE操作。
【关键前提】每次提问必须包含时间范围、聚合方式、排序方向等完整约束。例如不能只问“复购用户”，而要写“近90天内下单≥2次的用户”——Qwen3-VL不会自动补全业务规则。
执行SQL前的三重校验
步骤一：检查WHERE条件中的时间函数是否匹配MySQL版本
MySQL 8.0支持DATE_SUB(NOW(), INTERVAL 1 MONTH)，但5.7不支持INTERVAL关键字，需改用DATE_SUB(NOW(), INTERVAL 30 DAY)或STR_TO_DATE()。模型默认按8.0生成，你必须人工核对版本。
步骤二：验证字段别名是否唯一
若问题含“显示用户姓名和订单金额”，模型可能生成SELECT u.name, o.amount AS name ——这里AS name造成列名冲突，执行时会报ERROR 1060。需扫描SELECT子句中所有AS后名称，确保无重复。
步骤三：确认LIMIT是否置于末尾
Qwen3-VL偶尔把LIMIT 5写在WHERE之前，导致语法错误。正确位置必须在ORDER BY之后、分号之前。
完成这三步校验后，将最终SQL粘贴至MySQL客户端执行。
