摘要
我们与斯坦福大学、威斯康星大学麦迪逊分校以及Bauplan合作，测试了LLM能否优化数据库查询执行计划。结果表明，LLM引导的计划重写可以在不修改数据库引擎本身的情况下提高执行性能。
近期AI的进步得益于底层系统基础设施的改进。但这种关系并非必须不对称：AI和LLM也可以用于优化大规模系统本身的功能组件。我们最近的论文展示了如何将AI用于数据库查询优化。
传统的查询优化依赖于基于成本的估算器，这些估算器使用统计模型和预定义启发式方法计算执行路径。当执行类似"查找所有涉及太空旅行的科幻节目"这样的查询时，优化器必须决定执行策略：是先筛选科幻节目，再检查哪些涉及太空旅行，还是反过来？如果数据分布在多个表中（例如，一个节目表和一个类型表），应该先扫描哪个表，以及如何连接它们？优化器通过估算每个条件匹配的行数来回答这些问题，然后选择估算成本最低的实际计划（操作的顺序）。
然而，这些估算通常假设属性独立。 考虑一个流媒体服务数据集，你想查找既是"科幻"又"涉及太空旅行"的节目。如果15%的节目是科幻，8%涉及太空旅行，假设独立性会估算出1.2%的节目同时满足两个条件（15% × 8%）。然而，涉及太空旅行的节目绝大多数是科幻，因此实际重叠接近7%——比预测高出近6倍。
事实上，这些系统通常运行良好，但当启发式方法未能考虑模式或数据中的语义相关性时，就会遇到困难。正如Lohman（2014）的一个例子所指出的，基数估计是优化器效率低下的主要来源，因为行数估算误差会通过成本模型传播，并可能导致连接顺序、访问路径和物理操作符的系统性错误选择。这种数量级的误差会导致次优的物理计划，需要大量工程工作手动纠正。
查询优化是一个已解决的问题吗？
这些估算误差的持续存在表明，物理规划并非一个已解决的问题，尤其是在函数依赖关系常见的复杂OLAP工作负载中。
为了解决这个问题，我们引入了DBPlanBench，这是一个暴露Apache DataFusion引擎查询执行过程的工具。该系统将内部物理操作符图（包括连接策略和分区方案）暴露给LLM。这里的主要技术挑战是原始物理计划中固有的信息密度，其中包含冗长的文件路径、分区元数据和类型编码，这些会迅速填满上下文窗口。
如果没有仔细的序列化，整个计划可能超过200万字符，使得LLM无法高效地推理输入。我们的工具实现了一个序列化层，遍历引擎的物理算子图，并将异构对象映射到一个统一的、token高效的JSON模式。
这种表示方法去重了文件级统计信息，并移除了与执行无关的字段，使得负载比原生序列化小约10倍。
DBPlanBench从而将优化任务从统计计算转化为语义推理问题，其中LLM分析计划的拓扑结构，以识别连接顺序中的逻辑缺陷。
为了安全地实施这些修复，我们指示LLM避免从头重新生成整个物理计划；相反，它对DataFusion现有的物理计划应用有针对性的编辑，降低了语法错误或无效计划拓扑的风险。具体来说，LLM生成JSON补丁（RFC 6902），描述局部编辑，例如交换连接侧或重新排序节点。这些补丁比完整计划小几个数量级，并直接应用于序列化图，确保执行DAG的结构完整性。
案例研究
统计估计失败的后果在查询延迟和系统资源消耗上都是可衡量的。在从TPC-DS衍生版本生成的涉及跨渠道销售的特定查询中，默认的DataFusion优化器优先连接较小的item表（36K行），然后连接较大的日期维度表（73K行），假设较小的连接更便宜。这种启发式方法未能考虑日期维度上过滤器d_year=2001的高选择性。LLM优化的计划颠倒了这个顺序，在后续连接之前尽早应用日期过滤器，将销售事实表从1510万行修剪到290万行。
这种结构优化使查询速度提升了4.78倍。更重要的是，资源占用大幅减少。优化后的计划将聚合哈希表构建时间从10.16秒减少到0.41秒，并将总构建内存使用从3.3 GB削减到411 MB。实验表明，在TPC-H和TPC-DS生成的查询工作负载上，中位数加速比约为1.1倍到1.2倍，该方法在一些复杂的多连接查询上也带来了更大的收益，例如加速比高达4.78倍，其他几个在1.5-1.7倍范围内。
进化式计划修补
我们通过迭代优化来演进查询计划。系统使用GPT-5生成候选改进（通过JSON补丁），验证每个更改，并保留减少延迟的补丁。一旦应用这些补丁，系统会再次尝试从新计划开始生成新的候选。通过在多个步骤中基于成功的优化进行构建，这种进化方法比简单地独立采样多个计划实现了更好的加速。
并非所有查询都能被有效优化，因为计划可能已经是最优的，但我们发现在采样数据集中，60.8% 的查询可以被优化超过 5%。下图展示了我们在一个派生数据集上的改进：
跨规模因子的加速迁移
我们使用的基准测试暴露了一个规模因子参数，该参数在保持底层模式固定的同时缩放表基数。在实践中，这让我们能够构建一个较小的原型数据库（例如，规模因子 3，即 SF3）和一个较大的生产级数据库（例如，SF10），它们共享相同的结构，仅在规模上有所不同。
由于在全量数据上探索大量候选计划代价高昂（每一步都需要执行查询，并支付和等待 LLM 生成的补丁），我们首先在 SF3 上使用进化搜索发现良好的优化计划。然后，对于每个查询，我们使用确定性的基于规则的脚本将最佳 SF3 计划迁移到 SF10。该脚本通过规范化模式/投影/谓词签名匹配跨规模的扫描运算符，并将 SF3 优化计划重写为可运行的 SF10 计划，保留结构编辑（如连接重排序和连接侧交换），同时执行安全检查（例如，无悬空引用，有效的 DAG 拓扑）。
经验上，我们在 SF3 上选择的每个优化计划都能成功迁移到 SF10，并且产生的加速与原始加速紧密相关。这验证了一种实用的“小规模优化，大规模部署”工作流：在工作负载的紧凑副本上执行一次昂贵的搜索，然后将结果计划提升到更大的生产数据库，只需最少的额外工程工作。
结论
DBPlanBench 证实了 LLM 可以有效地作为语义基数估计器，纠正统计启发式方法遗漏的物理计划错误。通过将紧凑的计划序列化与进化补丁搜索相结合，该系统在不修改核心数据库引擎的情况下，显著减少了执行时间和内存压力。工具和代码已作为开源发布，以供进一步研究。
参考文献
Lohman, G. Is query optimization a “solved” problem? ACM SIGMOD Blog, April 2014. URL: https://wp.sigmod.org/?p=1075. Accessed: 2026-01-26.