引言
随着大型语言模型（LLMs）在技术领域的应用日益广泛，评估这些模型在特定技术任务上的能力变得越来越重要。本研究聚焦于四款领先的推理模型——DeepSeek r1、GPT-4o、Kimi k1.5和Claude 3.7 Sonnet在SQL理解与分析方面的能力，特别是它们判断SQL查询等价性的表现。
评测方法
我们设计了一个具有挑战性的测试案例[注1]：使用TPC-H基准测试中的一个原始SQL查询，以及通过专业SQL优化工具PawSQL重写后的查询版本。这两个查询在语法结构上有明显差异，但在语义上是等价的。我们要求四个模型分析这两个查询是否等价，并评估它们的推理过程和结论。
测试查询
原始SQL查询
select ps.ps_partkey, sum(ps.ps_supplycost * ps.ps_availqty) as value
from partsupp as ps, supplier, nation
where ps.ps_suppkey = supplier.s_suppkeyand supplier.s_nationkey = nation.n_nationkeyand nation.n_name = 'JAPAN'
group by ps.ps_partkey
having sum(ps.ps_supplycost * ps.ps_availqty)> (select sum(ps_supplycost * ps_availqty) * 0.0001from partsupp, supplier, nationwhere ps_partkey = ps.ps_partkeyand ps_suppkey = s_suppkeyand s_nationkey = n_nationkeyand n_name = 'JAPAN')
order by value desc重写优化后的SQL查询：标量子查询解关联
select ps.ps_partkey, sum(ps.ps_supplycost * ps.ps_availqty) as value
from partsupp as ps, supplier, nation , (select ps_partkey, sum(ps_supplycost * ps_availqty) * 0.0001 as null_from partsupp, supplier, nationwhere ps_suppkey = s_suppkeyand s_nationkey = n_nationkeyand n_name = 'JAPAN'group by ps_partkey) as SQ
where ps.ps_suppkey = s_suppkeyand s_nationkey = n_nationkeyand n_name = 'JAPAN'and SQ.ps_partkey = ps.ps_partkey
group by ps.ps_partkey
having sum(ps.ps_supplycost * ps.ps_availqty) > sum(SQ.null_)
order by value desc模型分析结果
DeepSeek r1（推理用时59秒）
DeepSeek r1推理用时约59秒，正确判断两个查询在逻辑上等价的。
它的分析重点包括：
-
查询逻辑对比：区分了第一个查询使用关联子查询与第二个查询使用内联视图预计算的不同实现方式。
-
等价性验证：详细分析了子查询作用域、计算值一致性和过滤条件，指出第二个查询中的
sum(SQ.null_)实际上等价于直接取SQ.null_，因为每个ps_partkey在SQ中唯一。 -
性能差异：识别出第二个查询通过预计算和连接优化避免了多次扫描，执行效率可能更高。PawSQL的优化结果也确实证明整体性能从192秒降低到0.065s，性能提升超过1000倍[1]。
GPT-4o（推理时间26秒）
GPT-4o推理用时26秒，同样得出了两个查询等价的正确结论。
它的分析主要关注：
-
子查询的写法差异：识别出第一个SQL使用相关子查询，而第二个SQL将计算逻辑放到内联子查询中。
-
执行方式差异：指出尽管执行计划有所不同，但两个查询的语义和最终结果相同。
GPT-4o的分析简洁明了，直接抓住了查询优化的本质：通过提前计算派生表的聚合值以提高性能，同时保持结果一致性。
Kimi k1.5（用时1分钟8秒）
Kimi k1.5推理用时1分钟8秒，而且错误地认为两个查询不完全等价。
其重点分析包括：
-
子查询位置和逻辑：认为两个查询在子查询位置和处理逻辑上存在差异。
-
分组和筛选逻辑：误解了第一个查询是全局计算一个单一阈值，而第二个查询按
ps_partkey分组计算独立阈值。 -
结果差异：基于上述误解，得出两个查询可能返回不同结果的错误结论。
Kimi的分析反映出它在理解SQL查询语义，特别是子查询与主查询关系方面的局限性。
Claude 3.7 Sonnet
Claude 3.7 Sonnet也得出了查询不等价的错误结论。
它的分析关注点包括：
-
子查询处理方式：正确识别出两个查询在子查询实现上的差异。
-
HAVING子句条件比较：误认为第二个查询中的
sum(SQ.null_)会对派生表结果再次聚合，改变比较语义。 -
修改建议：提出将第二个查询的HAVING条件修改为直接使用SQ
.null_而非sum(SQ.null_)。
Claude的分析显示了对SQL聚合函数在不同上下文中行为理解的不足。
评测结论
-
DeepSeek r1和GPT-4o展示了较强的SQL语义理解能力，不仅给出了正确结论，还能准确解释优化过程中的语义保持。
-
Kimi k1.5和Claude 3.7 Sonnet在处理复杂SQL转换和子查询优化时存在明显局限，尤其是在理解聚合函数与JOIN操作的交互方面有待提高。
-
模型表现差异可能反映了训练数据中SQL相关内容的质量和数量差异，以及模型对数据库查询执行机制的理解深度不同。
启示
尽管大型语言模型在SQL理解和分析方面取得了显著进展，本研究结果也凸显了专业SQL优化工具（如PawSQL）在实际数据库优化工作中的不可替代性。
-
优化精确性与可靠性：专业工具基于数据库理论和实践，确保查询转换的语义等价性，而LLMs在复杂SQL查询的理解上仍存在不确定性。
-
性能优化的系统性与全面性：专业工具可以基于数据库引擎特性和统计信息进行优化，考虑索引使用、连接顺序、谓词下推等多维度优化，生成可预测的、一致的优化结果。
-
生产环境中的稳定性与可控性：在生产环境中，SQL查询优化需要考虑优化的可预测性和一致性、与现有应用系统的兼容性以及对边缘情况的稳健处理。专业工具在这些方面提供了更高的可靠性和可控性。
-
工具协同: 构建LLMs与专业SQL优化工具协同工作的方法，可能是提高数据库优化效率和可靠性的有效途径。
总结
通过SQL等价性分析任务，揭示了当前顶级推理模型在处理专业技术领域问题时的能力差异。尽管部分模型展现了对SQL语义理解的能力，但专业SQL优化工具在实际生产环境中的价值仍不可替代。随着技术发展，LLMs与专业工具的结合使用可能成为未来数据库优化的最佳实践。
[*注1] 本文使用的优化案例：
https://www.pawsql.com/statement/1897947325217640449
