4B模型把数据库查询提速81%

4B模型开始挑战PostgreSQL优化器

一款只有40亿参数的专用模型，最近把PostgreSQL默认查询计划甩在了身后。

截至2026年9月16日，开发者Rohan Bansal公布了一项名为QORL的实验：通过面向查询执行反馈训练一个4B模型，让模型为SQL选择更高效的查询计划；在作者使用的测试集合中，这些计划的执行速度比PostgreSQL默认优化器生成的计划快81%。

QORL是一个用执行结果训练语言模型生成数据库查询计划的实验项目。它的目标不是让模型解释SQL，也不是生成看起来更优雅的语句，而是直接影响数据库最核心的决策之一：表先怎么连接、用哪种Join、从哪里开始扫描，以及中间结果如何流动。

这个结果值得重视，因为查询优化过去一直被认为是数据库内核中最不适合交给通用语言模型的部分。模型要处理的不是语法补全，而是一个高度依赖数据分布、统计信息、硬件环境和执行代价的组合优化问题。

但“快81%”也必须放回实验条件中理解。它证明了4B小模型可以在特定工作负载上学会超越传统成本模型，却还不能证明它在任意数据库、任意数据分布和生产环境里都比PostgreSQL可靠。

它优化的不是SQL文字，而是SQL怎么跑

查询计划是数据库执行一条SQL时采用的具体操作路径。相同的SQL可以对应完全不同的执行方式，而这些方式的耗时可能相差数倍，极端情况下甚至相差几个数量级。

例如，一条包含多表连接的分析查询，可以先过滤小表再连接大表，也可以先把两个大表做Join；它可以选择Nested Loop、Hash Join或Merge Join，还可以在顺序扫描与索引扫描之间做取舍。SQL文本没有改变，但实际读取的数据页数量、中间结果规模和内存占用会完全不同。

PostgreSQL查询优化器是一个基于统计信息和成本模型的计划搜索系统。它会估算每个候选计划需要处理多少行、进行多少次随机I/O和顺序I/O，再从可搜索的候选空间里选择估算成本最低的方案。

开发者通常会用下面这样的命令观察实际计划：

EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)
SELECT ...
FROM orders
JOIN customers ON ...
WHERE ...;

这套机制已经被打磨了几十年，但它仍有一个老问题：优化器依赖的基数估计可能出错。基数估计是数据库对一个过滤或连接操作将产生多少行数据的预测，一旦把实际100万行估成100行，后续Join顺序和算法选择就可能全部偏离。

QORL的核心思路，是让模型从执行反馈中学习传统成本模型没有捕捉到的模式。模型不只学习“语法上什么计划成立”，还要学习“什么计划在真实执行中更快”。

81%到底意味着什么

“比PostgreSQL快81%”是这次实验最吸睛、也最容易被误读的数字。作者使用它描述模型所生成查询计划相对于PostgreSQL默认计划的执行性能优势，但该数字不能脱离测试集、聚合方式、缓存状态和超时处理规则单独比较。

如果这里指执行时间降低81%，那么一条原本需要100秒的查询会缩短到约19秒，相当于约5.26倍速度提升；如果它指吞吐性能提高81%，则对应的时间缩短比例约为44.8%。数据库基准中这两种表达并不等价，因此更严谨的报告还需要同时公开原始延迟、中位数、P95、最长查询和逐条查询结果。

这项实验目前最有价值的结论不是“PostgreSQL优化器已经过时”，而是“模型能够学习优化器的系统性盲点”。传统优化器根据统计摘要推断代价，模型则有机会从大量历史查询、执行计划和真实耗时中提取跨查询规律。

下面是几类方案的直接对比：

| 方案 | 决策依据 | 主要输出 | 已公开结果 | 优势 | 当前短板 | |---|---|---|---|---|---| | QORL 4B模型 | SQL、数据库上下文与执行反馈 | 候选查询计划或计划约束 | 作者测试中比PostgreSQL默认计划快81% | 参数量小，可针对固定工作负载训练 | 泛化范围、训练成本和完整分布数据仍需验证 | | PostgreSQL默认优化器 | 统计信息、成本参数与规则搜索 | 原生执行计划 | 无统一固定提升值 | 无模型推理开销，稳定且可解释 | 基数估计错误可能导致灾难性计划 | | SQL重写工具 | 规则、语义分析或大模型推理 | 改写后的SQL | 不同基准差异较大 | 容易接入现有应用 | 可能改变语义，仍需数据库重新规划 | | 通用推理大模型 | 预训练知识与上下文推理 | SQL建议、索引建议或解释 | 与QORL暂无同口径结果 | 理解能力强，适合交互式诊断 | 成本高，输出不稳定，缺少执行闭环 |

2025年7月发布的一份大模型SQL能力评测中，SQLFlash在SQL优化项目上得到88.5分，DeepSeek-R1为71.6分，Claude Sonnet 4为70.9分，Qwen3-235B-A22B为69.1分，GPT-o4-mini为68.4分。但这些分数衡量的是SQL优化任务完成度，并不是查询计划的真实执行时间，不能与QORL的81%直接横向比较。

强化学习比“背答案”更适合这件事

执行反馈是查询优化最可靠、也最昂贵的监督信号。一个计划究竟好不好，最终要看它在真实数据库上跑了多久、读了多少数据页、使用了多少内存，以及是否发生磁盘临时文件溢写。

这类任务天然适合强化学习。模型生成候选计划，数据库负责执行，系统再根据延迟或代价给出奖励；更快的计划得到正反馈，超时、报错或更慢的计划得到惩罚。它类似让模型在一个可验证环境里反复做实验，而不是只模仿人工写下来的“标准答案”。

查询优化也属于结果容易验证、过程难以标注的问题。人类数据库专家可以判断一条查询很慢，却很难为每个复杂Join穷举出全局最优计划；数据库执行器则可以直接告诉训练系统，计划A用了3秒，计划B用了600毫秒。

不过，直接使用查询耗时作为奖励会引入大量噪声。缓存是否预热、后台任务是否抢占CPU、数据页是否已进入操作系统Page Cache、并发连接数量以及磁盘状态，都可能让同一个计划的耗时发生波动。

一个可信的训练和评测流程至少需要控制以下变量：

• 同一计划重复执行多次，并报告中位数和尾延迟；
• 区分冷缓存、数据库缓冲区缓存和操作系统缓存；
• 为慢查询设置统一超时，避免少数坏计划拖垮训练；
• 验证候选计划与原查询语义一致；
• 隔离模型推理时间与数据库执行时间；
• 在未参与训练的查询模板和新数据分布上测试泛化能力。

如果这些细节没有完整披露，81%更适合被视为一个强烈的可行性信号，而不是生产级SLA承诺。

4B不是重点，小而专才是重点

4B模型是参数规模约40亿的语言模型。以BF16或FP16保存权重时，仅模型参数理论上约需8GB显存；采用8位量化约需4GB，4位量化约需2GB，但实际部署还要预留KV Cache、运行时缓冲区和框架开销。

这个体量意味着QORL不必依赖超大模型集群。对于固定数据库、稳定Schema和重复分析查询较多的团队，4B模型可以部署在单张消费级或工作站级GPU上，也可以在量化后使用高内存CPU环境运行。

更重要的是，数据库优化并不需要模型掌握所有世界知识。它需要的是对关系代数、Join组合、统计偏差和特定工作负载的深度适配，而不是写诗、识图或回答百科问题。

这种“小模型加可验证环境”的路线，可能比直接调用数千亿参数通用模型更合理。大模型在解释慢查询、生成索引建议和分析业务语义方面更有优势；小模型则适合在边界明确、奖励清晰的计划空间里快速搜索。

QORL也展示了蒸馏之外的另一种小模型价值。小模型不一定只是复制大模型答案，它还可以依靠环境反馈，在一个狭窄但高价值的任务上学到通用大模型没有被专门训练过的策略。

它不会立刻替代PostgreSQL优化器

PostgreSQL默认优化器的最大优势不是每次都选到最快计划，而是能够在极低决策成本下覆盖海量未知查询。它不需要为每个客户数据库单独训练，也不会因为模型幻觉生成语法上不存在的执行节点。

模型优化器则必须解决分布外问题。训练时只有5张表，生产中突然出现20张表；训练时数据均匀分布，上线后某个租户占了90%的记录；训练时索引存在，迁移后索引被删除——这些变化都可能让模型失去判断依据。

模型推理延迟同样不能忽略。如果一条OLTP查询原本只需要2毫秒，而模型选择计划要花100毫秒，那么即便执行阶段快了50%，端到端体验仍然更差。QORL更适合原本耗时数秒到数小时、计划质量决定总成本的分析查询，而不是每秒执行数万次的简单主键查询。

生产落地还需要一个“安全壳”。更现实的架构不是让模型接管所有查询，而是让它充当候选计划生成器，再交给数据库验证和回退机制处理。

一个相对稳妥的流程可以是：

1. PostgreSQL先生成默认计划，作为稳定基线；
2. 模型只处理成本超过阈值的复杂查询；
3. 候选计划先在影子环境或只读副本上执行；
4. 系统比较实际耗时、缓冲区读取量和资源占用；
5. 只有通过验证的计划才进入计划缓存；
6. 数据量、统计信息或Schema变化后自动失效并重新评估。

这种设计把模型从“不可控的数据库大脑”变成“可以被验证的搜索器”。它可能无法保证每次都比PostgreSQL聪明，但可以持续寻找默认优化器遗漏的更好方案，同时保留原生计划作为回退路径。

真正的机会在企业私有工作负载

QORL最可能产生价值的场景，是查询模板稳定、单条查询成本高且历史执行数据充足的企业数据库。数据仓库报表、广告归因、风控分析、财务结算和多表ETL任务，都比开放式SQL问答更适合这种训练方式。

企业数据库通常存在大量重复模式。SQL中的日期、租户ID和商品ID会变化，但Join结构、过滤逻辑和数据倾斜模式长期稳定；模型只要在这些模式上找到更好的计划，就可能持续节省计算资源。

这种收益也很容易换算成钱。一条每天运行1000次、每次60秒的查询，如果执行时间减少81%，每天可以从16.7小时数据库执行时间降至约3.2小时；但这个估算只有在81%代表执行时间降幅、且收益能稳定复现时才成立。

相比之下，完全陌生的临时查询并不是它的最佳战场。临时查询缺少历史反馈，数据分布也难以预测，这时PostgreSQL几十年积累下来的规则、统计信息和成本模型仍然更可靠。

这项实验真正改变了什么

QORL目前更像一个有说服力的研究原型，而不是可以一键替换PostgreSQL优化器的产品。它缺少的不是一个更大的参数规模，而是跨Schema评测、并发压力测试、数据漂移测试、完整逐查询分布以及长期运行稳定性。

这项实验依然跨过了一个重要门槛：数据库优化不再只是让大模型阅读EXPLAIN结果并给出建议，模型已经开始进入查询计划选择本身，并且能够通过真实执行反馈学会超过默认优化器。

对开发者而言，最值得关注的方向不是“用AI重写所有SQL”，而是“把模型放进可验证、可回退的数据库闭环”。计划选错可以退回默认方案，计划选对则可能直接省下数倍计算成本，这比让模型自由修改业务SQL更安全，也更容易量化价值。

对PostgreSQL而言，这也不是一场简单的替代关系。未来更可能出现的是混合优化器：传统成本模型负责稳定性、合法性和快速规划，学习型模型负责修正基数偏差、提出候选Join顺序，以及识别特定工作负载中的重复模式。

4B模型比PostgreSQL快81%的意义，最终不在于它赢下了一次基准测试，而在于它证明了数据库内核最难的决策之一，可以被一个足够小、能够私有部署、并由真实执行结果训练的模型有效介入。

参考来源

• PostgreSQL优化器源代码：PostgreSQL官方代码仓库中的查询规划与优化器实现。
• pg_hint_plan：用于通过Hint影响PostgreSQL执行计划的开源扩展，可用于理解外部计划干预方式。
• Join Order Benchmark：常用于研究多表连接顺序与查询优化器表现的公开基准。
• How Good Are Query Optimizers, Really 论文解读：介绍基数估计、成本模型和计划枚举对查询性能的影响。