SQL 调优该选哪个模型：从执行计划到实测的七步筛选法

选择 SQL 调优模型，不是找一个最会重写查询的模型，而是找一个能根据证据提出可验证改动、识别语义风险，并减少人工排查成本的助手。下面按一次真实调优任务的顺序，建立自己的选型流程。

1. 先确定要解决哪种慢

把目标写清楚：是降低单次查询延迟，减少扫描行数，还是缓解高并发下的资源竞争？同时记录数据库类型、版本、超时限制与业务约束。锁等待导致的慢查询，未必需要改写 SQL；没有这层区分，模型可能把所有问题都归结为缺索引。

2. 准备能解释瓶颈的上下文

提供原始 SQL、相关表结构、已有索引、表规模、过滤字段的数据分布，以及典型参数对应的执行计划。脱敏时保留字段类型、关联关系和分布特征，不要直接上传生产数据、连接凭据或用户信息。上下文不足时，让模型先列出缺失证据，而不是立即给出“最优查询”。

对于支持的数据库，可补充实际执行统计。但 EXPLAIN ANALYZE 通常会执行语句，应先确认数据库行为，并在隔离环境、只读副本或受控条件下采集，尤其不要直接对生产写操作使用。

3. 用同一任务比较两个候选

可以先把 DeepSeek V4 Pro 和 Claude Sonnet 5.5 作为候选，而不是预设谁更擅长数据库。通过 CodeRelay Hub 的统一接口，用相同上下文和输出要求分别调用，接口基础地址为 https://api.coderelayhub.com。统一入口便于切换模型，但仍需检查各模型支持的参数和上下文限制。

提示词应要求模型依次输出：瓶颈证据、待验证假设、最小改动、语义风险和验证步骤。先固定提示词再比较，避免把提示词改进误算成模型能力差异。

4. 检查它是否真正读懂执行计划

优先选择能把建议对应到具体计划节点的模型。例如，过滤发生得太晚、连接输入估算偏差明显，或排序出现磁盘溢出，都应说明依据。仅凭出现全表扫描就建议加索引，并不可靠；当查询需要读取大部分数据时，顺序扫描可能更合理。

5. 把语义正确放在速度之前

要求模型逐项检查 NULL、重复行、外连接、聚合粒度，以及分页排序是否稳定。比如把 LEFT JOIN 改成 INNER JOIN，即使执行更快，也可能丢失业务需要的记录。验证时应比较结果内容及重复次数，不能只比较返回行数。

索引建议也要交代代价：新增索引会增加存储和写入维护开销；复合索引的列顺序需要结合过滤、排序与实际访问模式判断，不能套用固定口诀。

6. 只用本地实测决定是否采纳

在接近生产的数据规模上，对原查询与候选方案使用相同参数和测试条件。覆盖常见参数与偏斜参数，区分冷缓存、热缓存，并重复执行，记录延迟、扫描量、缓冲区读取及资源消耗。一次更快不代表稳定收益，也不能用模型自报的提速比例作为结论。

每轮尽量只改变一个因素，避免同时改写查询、添加索引和更新统计信息。否则即使性能改善，也难以解释原因，更难制定回滚方案。

7. 按完整工作成本选模型

最终比较的不只是调用费用，还包括响应等待、无效建议数量，以及工程师验证和返工的时间。对代表性查询记录同一份评分表：证据是否充分、语义是否正确、方案是否可执行、实测是否改善。若便宜的候选已能稳定完成任务，就没有必要默认升级。

可以把日常诊断交给成本合适的模型，仅在复杂连接、估算异常或多轮失败时切换候选。模型负责提出假设，数据库实测负责裁决；上线前仍需人工审核、监控和回滚准备。

欢迎开通 CodeRelay Hub 免费工作区。