Qwen大模型自动识别MySQL表结构设计缺陷避坑指南

用大模型分析MySQL表结构，听起来很诱人，对吧？你只需把DDL语句丢过去，几秒钟内它就能给出结论：“字段类型合理”，“索引配置得当”。但在真实业务场景中，情况往往残酷得多：一张表面四平八稳的表，一旦遭遇高并发写入就会死锁频发，执行一个JOIN查询可能直接超时，想在线修改字段更是被锁得死死的。这些致命陷阱，Qwen并不会主动告诉你。讽刺的是，它并非没有这个能力，关键在于你喂给它的是什么——不是一张DDL截图，而是一个包含完整上下文的“病例包”：包括表结构本身、访问日志，以及那些慢如蜗牛的查询样本。

这篇文章并非什么“教你怎么让模型看懂SQL”的入门指南。它要阐述的是，如何构造输入、如何设定边界、如何验证输出，从而让Qwen真正去揪出那些隐藏在CREATE TABLE语句背后的结构性隐患。建议按照以下三个步骤来操作。

第一步：准备带上下文的原始数据包

只丢一个SHOW CREATE TABLE给Qwen，相当于让医生只看化验单，连患者的主诉都没问。病史必须完整。你需要打包这三类材料：

**【DDL语句】**、**【最近7天慢查询TOP10样本】**、**【该表每日读写QPS与峰值TPS监控截图】**。

这三样东西，一件也不能少。没有慢查询样本，模型根本不知道索引是否覆盖了那些高频WHERE条件；没有QPS数据，它默认你这张表是低频配置，连接池耗尽的风险自然会被忽略。

将这几项内容合并到一个Markdown文本块中，用---分隔开。注意，DDL必须是能复制粘贴的纯文本，而不是截图。慢查询样本则需要保留EXPLAIN FORMAT=TRADITIONAL的完整输出，光提供SQL语句是不够的。QPS数据用表格呈现，列名要老老实实标注timestamp、reads_per_sec、writes_per_sec。

一个容易被忽视的细节是：如果表中使用了JSON字段来存储关键业务属性，比如订单状态流转记录，那么就必须额外提供这个JSON字段的典型值样例，并标注出哪些键会被高频WHERE或ORDER BY使用。Qwen对JSON路径索引可行性的判断，严重依赖于你给出的实际键名和访问模式，这里多提供一些信息，后续能省下不少精力。

第二步：用结构化Prompt锁定分析维度

直接问“这张表设计有没有问题”，得到的往往是一些正确的废话。你必须强制它按照四个硬性维度进行检查，一个都不能少。

这里有两个具体的方法：

方法一：指令式约束
在Prompt开头就给它定好调：“你是一名拥有5年MySQL内核调优经验的DBA，正在审计生产环境表。请严格按以下四点输出，每点必须标注‘通过’或‘风险’，并给出修复命令示例：

1. 主键设计是否引发热点写入（检查主键是否单调递增且无业务含义）；
2. 索引覆盖是否满足所有慢查询的WHERE+ORDER BY+SELECT字段；
3. 外键约束是否缺失导致应用层数据不一致（对比关联表的业务逻辑）；
4. 字段类型是否造成隐式转换（重点检查VARCHAR与INT比较、DATETIME与时区处理）。”

方法二：反事实引导
追加一句：“如果这张表明天要支撑日均500万订单写入，请指出当前设计中会在第3天凌晨2点首次触发的瓶颈点，并说明现象（如：唯一索引争用导致insert延迟突增至800ms）。”这种场景模拟，能迫使Qwen跳出静态的语法分析，去模拟真实负载下的行为，最终得出的结论往往更贴近实际。

第三步：验证Qwen输出的关键断点

模型输出完成后，别急着信任。需要做几轮反向验证。

第一道检查：看它是否识别出自增主键与业务时间强耦合的问题。比如，一张表使用的是user_id bigint AUTO_INCREMENT PRIMARY KEY，同时有created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP。Qwen必须能指出“新用户注册集中在每小时整点，导致InnoDB页分裂加剧，建议改用雪花ID或UUID_SHORT()”。如果它只会说“主键类型合适”，那么这次分析基本可以弃用了。

第二道检查：让它对每个慢查询样本反向生成EXPLAIN结果。将Qwen输出的“应添加联合索引idx_status_created”拿去执行CREATE INDEX，然后用原来的慢查询跑一遍EXPLAIN。如果type仍然是ALL，或者扫描行数没有下降90%以上，那就说明Qwen的索引建议有误。很可能是它误判了WHERE条件的选择率，此时需要把实际执行计划截图回传给模型，要求重新分析。

第三道检查：重点关注JSON字段的评估。如果Qwen说“JSON字段设计合理”，可以负责任地说，它大概率没有经过思考。立即追问：“该JSON中status_history数组平均长度23，最大嵌套深度4，当前查询中92%的请求只取status_history[0].code，是否应该拆出独立字段？若拆出，如何保证原子性更新？”【Qwen如果无法回答此问题，就证明它根本没理解这个JSON字段的真实访问模式】。此时，人工介入是必须的，采用MySQL 8.0.23+的多值索引或生成列重建方案，才是正道。