引言

隨著大型語言模型（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秒，正確判斷兩個查詢在邏輯上等價的。

它的分析重點包括：

1. 查詢邏輯對比：區分了第一個查詢使用關聯子查詢與第二個查詢使用內聯視圖預計算的不同實現方式。

2. 等價性驗證：詳細分析了子查詢作用域、計算值一致性和過濾條件，指出第二個查詢中的sum(SQ.null_)實際上等價于直接取SQ.null_，因為每個ps_partkey在SQ中唯一。

3. 性能差異：識別出第二個查詢通過預計算和連接優化避免了多次掃描，執行效率可能更高。PawSQL的優化結果也確實證明整體性能從192秒降低到0.065s，性能提升超過1000倍[1]。

GPT-4o（推理時間26秒）

GPT-4o推理用時26秒，同樣得出了兩個查詢等價的正確結論。

它的分析主要關注：

1. 子查詢的寫法差異：識別出第一個SQL使用相關子查詢，而第二個SQL將計算邏輯放到內聯子查詢中。

2. 執行方式差異：指出盡管執行計劃有所不同，但兩個查詢的語義和最終結果相同。

GPT-4o的分析簡潔明了，直接抓住了查詢優化的本質：通過提前計算派生表的聚合值以提高性能，同時保持結果一致性。

Kimi k1.5（用時1分鐘8秒）

Kimi k1.5推理用時1分鐘8秒，而且錯誤地認為兩個查詢不完全等價。

其重點分析包括：

1. 子查詢位置和邏輯：認為兩個查詢在子查詢位置和處理邏輯上存在差異。

2. 分組和篩選邏輯：誤解了第一個查詢是全局計算一個單一閾值，而第二個查詢按ps_partkey分組計算獨立閾值。

3. 結果差異：基于上述誤解，得出兩個查詢可能返回不同結果的錯誤結論。

Kimi的分析反映出它在理解SQL查詢語義，特別是子查詢與主查詢關系方面的局限性。

Claude 3.7 Sonnet

Claude 3.7 Sonnet也得出了查詢不等價的錯誤結論。

它的分析關注點包括：

1. 子查詢處理方式：正確識別出兩個查詢在子查詢實現上的差異。

2. HAVING子句條件比較：誤認為第二個查詢中的sum(SQ.null_)會對派生表結果再次聚合，改變比較語義。

3. 修改建議：提出將第二個查詢的HAVING條件修改為直接使用SQ.null_而非sum(SQ.null_)。

Claude的分析顯示了對SQL聚合函數在不同上下文中行為理解的不足。

評測結論

1. DeepSeek r1和GPT-4o展示了較強的SQL語義理解能力，不僅給出了正確結論，還能準確解釋優化過程中的語義保持。

2. Kimi k1.5和Claude 3.7 Sonnet在處理復雜SQL轉換和子查詢優化時存在明顯局限，尤其是在理解聚合函數與JOIN操作的交互方面有待提高。

3. 模型表現差異可能反映了訓練數據中SQL相關內容的質量和數量差異，以及模型對數據庫查詢執行機制的理解深度不同。

啟示

盡管大型語言模型在SQL理解和分析方面取得了顯著進展，本研究結果也凸顯了專業SQL優化工具（如PawSQL）在實際數據庫優化工作中的不可替代性。

1. 優化精確性與可靠性：專業工具基于數據庫理論和實踐，確保查詢轉換的語義等價性，而LLMs在復雜SQL查詢的理解上仍存在不確定性。

2. 性能優化的系統性與全面性：專業工具可以基于數據庫引擎特性和統計信息進行優化，考慮索引使用、連接順序、謂詞下推等多維度優化，生成可預測的、一致的優化結果。

3. 生產環境中的穩定性與可控性：在生產環境中，SQL查詢優化需要考慮優化的可預測性和一致性、與現有應用系統的兼容性以及對邊緣情況的穩健處理。專業工具在這些方面提供了更高的可靠性和可控性。

4. 工具協同:?構建LLMs與專業SQL優化工具協同工作的方法，可能是提高數據庫優化效率和可靠性的有效途徑。

總結

通過SQL等價性分析任務，揭示了當前頂級推理模型在處理專業技術領域問題時的能力差異。盡管部分模型展現了對SQL語義理解的能力，但專業SQL優化工具在實際生產環境中的價值仍不可替代。隨著技術發展，LLMs與專業工具的結合使用可能成為未來數據庫優化的最佳實踐。

[*注1] 本文使用的優化案例：

https://www.pawsql.com/statement/1897947325217640449