机械硬盘内部盘片与磁头组件的特写

先看结果

Rohan Bansal 在 9 月 16 日公布了一个实验：用一个 4B 规模的开源模型为 Postgres 生成执行计划，在 113 条以多表连接为主的查询上，几何平均提速 1.81 倍，总体延迟下降 44.7%，68 条更快、0 条回退。而这个模型刚开始连计划都写不出来——113 条里有 99 条它根本没能生成出合法计划。

为什么查询优化器是老大难

作者先讲清了一件事：数据库的优化器不是不够聪明，是这道题在数学上就难。连接顺序的选择是 NP-hard 问题，表一多，穷举的搜索空间会爆炸。于是优化器改用统计信息估算每个中间结果的行数，再按估算挑计划。估算一旦偏了，计划就会崩——2015 年和 2025 年两篇同题论文都在追问同一件事：优化器到底有多好？答案是还有很大空间。

关键的转折：好坏可以测出来

连接顺序难算，但判断一个计划好不好却非常简单：跑一遍，看耗时。这条「可验证」的性质，正是强化学习最擅长的地方。做法是对同一条查询让模型给出 4 个候选计划，交给真实数据库去跑，用实测的执行时间打分，再把分数回传去更新模型权重。训练分在两台机器上：租来的 2×H100 节点跑推理服务与训练器，桌面上的四台容器跑 Postgres 负责测量。

更细的一点在测量环境：多个容器并发会争抢页面缓存，噪声会让奖励信号自己抖起来，所以作者专门做了一套让测量结果稳定的装置。奖励不可信，训练就没有意义。

计划能力是怎么教出来的

训练分成两段。先用监督微调做离策略蒸馏：拿大约五百条前沿智能体跑出来的轨迹当样本，让 4B 模型先学会「一个执行计划长什么样、该怎么表达」。第二阶段才是强化学习：同一条查询采样多次，用相对优势给每次采样打分，把比平均更好的那些策略留下来。作者特别提到，奖励设计要处理噪声——测量环境本身在抖，如果直接拿绝对耗时当奖励，模型学到的会是测量误差，而不是真本事。

值得拿走的三个判断

第一，小模型的胜负手是反馈质量，不是参数量。第二，成熟系统里的「老师傅经验」——选路径、调参数、定策略——正在变成可训练的目标，前提是你先有一把能衡量好坏的尺子。第三，动手之前先问：我的场景里有没有这样一个可测量的指标？有指标的地方，才是 AI 能稳定发挥的地方。