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