用 LLM 优化数据库查询，提速 4.78 倍

AI 的进步离不开底层系统基础设施的改进，但这种关系并非单向——AI 和大语言模型（LLM）同样能用来优化大规模系统自身的功能组件。我们最近的研究论文展示了如何用 AI 优化数据库查询。

传统查询优化依赖基于成本的估算器，它使用统计模型和预定义启发式方法来计算执行路径。执行类似 “找出所有涉及太空旅行的科幻剧” 的查询时，优化器必须决定执行策略：是先筛选科幻剧再检查哪些涉及太空旅行，还是反过来？如果数据分布在多个表（例如剧集表和类型表）中，应该先扫描哪个表，以及如何连接它们？优化器通过估算每个条件将匹配多少行来回答这些问题，然后选择预估成本最低的实际计划（操作顺序）。

然而，这些估算通常假设属性独立。 考虑一个流媒体服务数据集，你想找到既是“科幻”又“涉及太空旅行”的剧集。如果 15% 的剧集是科幻剧，8% 涉及太空旅行，假设独立性会估算出 1.2% 的剧集同时满足两个条件（15% × 8%）。但实际上，涉及太空旅行的剧集绝大多数是科幻剧，实际重叠率接近 7%——比预测值高出近 6 倍。

事实上，这些系统通常运行良好，但当启发式方法未能考虑模式或数据内的语义关联时就会出问题。正如 Lohman（2014 年）在一个例子中指出的，基数估计是优化器效率低下的主要根源，因为行数误估会通过成本模型传播，并可能导致系统性地选择错误的连接顺序、访问路径和物理运算符。这种数量级误差会导致次优的物理计划，需要大量工程努力手动纠正。

语义感知的连接优化。通过将选择性的 date 过滤器提前，LLM 重新排序计划，使销售事实表在连接前从 1510 万行修剪到 290 万行，从而获得更快的查询。

查询优化是已解决的问题吗？

这些估计误差的持续存在表明，物理规划并非已解决的问题，尤其是在功能依赖常见的复杂 OLAP 工作负载中。

为了解决这个问题，我们引入了 DBPlanBench，这是一个执行框架（Harness），它暴露了 Apache DataFusion 引擎的查询执行过程。该系统将内部物理运算符图（包括连接策略和分区方案）暴露给 LLM。这里的主要技术挑战是原始物理计划中固有的信息密度，其中包含冗长的文件路径、分区元数据和类型编码，会快速填满上下文窗口（Context Window）。

如果不进行仔细的序列化，整个计划可能超过 200 万个字符，使得 LLM 无法有效且高效地对输入进行推理。我们的执行框架实现了一个序列化层，它遍历引擎的物理运算符图，并将异构对象映射到统一的、节省 Token 的 JSON 模式中。

压缩单个表引擎统计数据的说明性片段。完整的 JSON 包含许多与执行无关的字段（例如 precisionInfo、每列的最小值/最大值和空值计数），而简明的统计数据仅保留主要信号，如 n_rows 和 total_bytes。

这种表示法去重了文件级统计数据，并移除了与执行无关的字段，产生的负载比原生序列化小约 10 倍。

因此，DBPlanBench 将优化任务从统计计算转换为语义推理问题，其中 LLM 分析计划的拓扑结构以识别连接顺序中的逻辑缺陷。

我们在 DataFusion 内部优化物理计划的优化执行框架。

为了安全地实施这些修复，我们指示 LLM 避免从头开始重新生成整个物理计划；相反，它对 DataFusion 现有的物理计划进行有针对性的编辑，从而降低语法错误或无效计划拓扑的风险。具体来说，LLM 生成描述局部编辑的 JSON Patch（RFC 6902），例如交换连接两侧或重新排序节点。这些补丁比完整计划小几个数量级，并直接应用于序列化图，确保执行 DAG 的结构完整性。

交换 hashJoin 左右输入的 JSON Patch 示例，更新了子节点 ID 和连接键。它说明了如何通过一个小的局部补丁来重写连接（例如，将较小的表放在构建侧），而无需重新生成整个计划。

案例研究

统计估计失败的后果在查询延迟和系统资源消耗方面都是可测量的。在一个源自 TPC-DS 的跨渠道销售查询中，默认的 DataFusion 优化器优先连接较小的商品表（3.6 万行），然后再连接较大的日期维度表（7.3 万行），假设较小的连接成本更低。这种启发式方法未能考虑日期维度上过滤器 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 Patch），验证每个更改，并保留减少延迟的补丁。一旦应用了这些补丁，系统会尝试再次从新计划开始生成新的候选方案。通过在多个步骤中基于成功的优化进行构建，这种进化方法比简单地独立采样许多计划实现了更好的加速。

并非所有查询都能被有效优化，因为计划可能已经是最优的，但我们发现在我们的抽样数据集中，60.8% 的查询可以被优化超过 5%。下图显示了我们在一个衍生数据集上的改进：

在其中一个测试数据集（120 个查询）上的加速分布。虽然我们可以优化更大比例的查询，但有趣的是，我们可以优化约 30% 的查询，使其加速超过 10%。

跨比例因子迁移加速

我们使用的基准测试暴露了一个比例因子参数，该参数在保持底层模式固定的同时缩放表基数。实际上，这让我们可以构建一个较小的原型数据库（例如，比例因子 3，或 SF3）和一个较大的类似生产环境的数据库（例如，SF10），它们共享相同的结构，但仅大小不同。

因为在全规模数据上探索许多候选计划成本高昂（每个步骤都需要执行查询加上支付并等待 LLM 生成的补丁），我们首先使用进化搜索在 SF3 上发现良好的优化计划。对于每个查询，然后我们使用确定性的、基于规则的脚本将最佳的 SF3 计划迁移到 SF10。该脚本通过规范化的模式/投影/谓词签名匹配跨比例的扫描运算符，并将 SF3 优化计划重写为可运行的 SF10 计划，同时保留结构编辑（如连接重新排序和连接侧交换），并强制执行安全检查（例如，没有悬空引用，有效的 DAG 拓扑）。

经验表明，我们在 SF3 上选择的每个优化计划都可以成功迁移到 SF10，并且由此产生的加速比与原始加速比紧密相关。这验证了一个实用的“小规模优化，大规模部署”工作流：在紧凑的工作负载副本上运行一次昂贵的搜索，然后将结果计划以最小的额外工程工作提升到更大的生产数据库。

在小型 SF3 数据库上发现的加速在很大程度上延续到较大的 SF10 数据库。每个点代表一个查询，比较其在 SF3（x 轴）和 SF10（y 轴）上的加速。

结论

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.