技术深度解析
SQL连接顺序优化的核心挑战在于可能连接序列的组合爆炸。对于一个连接N个表的查询，可能的连接顺序约有(2N-2)!/(N-1)!种。传统的基于成本的优化器（CBO）依赖于基数估计——即对中间结果大小的预测——这些估计来自表统计信息，如直方图和不同值计数。当这些统计信息过时或不准确时，CBO会产生灾难性的糟糕计划。
LLM采用不同的方法。通过将查询模式、连接谓词和过滤条件编码为结构化提示，研究人员发现GPT-4和Claude 3.5等模型可以模拟人类DBA的推理过程。它们明确估计每个过滤器的选择性，计算中间连接的预期大小，并选择最小化最大中间结果的连接顺序。这与CBO的固定成本模型（例如CPU + I/O成本）有本质区别。LLM的推理是动态且上下文感知的。
该领域一个值得注意的开源项目是sql-optimizer-llm（GitHub，约2800星，自2025年初活跃）。它提供了一个框架，用于在JOB（Join Order Benchmark）数据集上对比LLM生成的连接顺序与PostgreSQL原生优化器的表现。该仓库包含一个提示工程工具包，允许用户注入基数提示和模式描述。最近的实验表明，GPT-4o在最多6个表的JOB查询上达到了94%的计划质量分数，而PostgreSQL为89%。
基准性能数据
| 模型 | 表数 ≤ 5 | 表数 6-10 | 表数 > 10 | 与PostgreSQL相比的平均计划成本降低 |
|---|---|---|---|---|
| GPT-4o | 97% | 88% | 62% | 23% |
| Claude 3.5 Sonnet | 95% | 84% | 55% | 19% |
| Gemini 2.0 Pro | 91% | 79% | 48% | 14% |
| Llama 3 70B（微调） | 89% | 72% | 41% | 11% |
| PostgreSQL CBO（基线） | 85% | 78% | 70% | 0% |
数据要点： LLM在中小型连接图（≤10个表）上显著优于传统优化器，但在超过该范围后性能急剧下降。微调的Llama模型虽然较弱，但具有本地部署且无API成本的优势。关键洞察在于，LLM在基数估计不确定的场景下表现出色——它们能比静态启发式方法更智能地“猜测”。
另一个关键技术细节是使用“思维链”（CoT）提示。没有CoT，LLM在连接排序上的性能下降超过40%。推理过程迫使模型显式计算中间基数，模仿人类“从最小的集合开始”的方法。这表明LLM并非在记忆执行计划，而是在执行一种学习到的优化形式。
关键参与者与案例研究
多家组织正在积极推动这一前沿。Neo4j一直在尝试将LLM驱动的查询规划用于其图数据库，其中类似连接的操作（遍历）甚至更为复杂。其内部研究表明，对于复杂的图模式，LLM可以将计划生成时间从几分钟缩短到几秒。
SingleStore（现属于更广泛的实时分析领域）已将基于LLM的顾问集成到其查询控制台中。该顾问不仅建议连接顺序，还用自然语言解释原因——例如，“我选择先连接‘orders’和‘customers’，因为对‘order_date’的过滤将‘orders’表减少了80%，使其成为最小的起点。”这种透明度是用户体验的重大改进。
DuckDB Labs开源了一个名为“LLM-Opt”的研究原型，它使用一个小的微调模型（基于Phi-3）为分析查询建议连接顺序。他们在TPC-H数据集上的基准测试显示，查询延迟平均改善15%，某些查询实现了3倍的加速。
竞争格局对比
| 公司/项目 | 方法 | 目标工作负载 | 关键指标 | 部署模式 |
|---|---|---|---|---|
| Neo4j（内部） | GPT-4 CoT用于图遍历 | 图查询 | 计划生成时间：2分钟 → 8秒 | 云API |
| SingleStore Advisor | Claude 3.5 + 自定义模式编码器 | 实时分析 | 用户满意度：+35% | SaaS |
| DuckDB LLM-Opt | 微调Phi-3（38亿参数） | OLAP / TPC-H | 平均延迟降低：15% | 本地/本地部署 |
| PostgreSQL + pg_llm_hint（社区） | 通过pg_hint_plan扩展的Llama 3 8B | 通用OLTP | 计划质量：JOB上+12% | 开源 |
数据要点： 市场正在分化为基于云API的方法（高准确率、高延迟、每次查询成本）和本地微调模型（准确率较低但零API成本、低延迟）。胜者很可能是混合模式：本地模型处理简单查询，云模型处理复杂查询。
行业影响与市场动态
数据库优化市场年估值约42亿美元（包括调优工具、托管服务和性能监控）。该领域正迎来变革。