上周五晚上，我在 HN 首页刷到一条标题，愣了一下：
Training a 4B model to produce 81% faster query plans than Postgres
81%。比 Postgres 默认计划快 81%。一个 4B 参数的小模型——比 LLaMA-3-8B 还小一半——能跑赢一个装在无数公司生产环境里、被无数 DBA 调教过的查询优化器。
我下意识反应是"标题党"。再点进去看了一眼作者 Rohan Bansal 的实验数据，默默关掉了 IDE 上正在写的慢查询排查文档。
因为我突然意识到，过去三年我一直在做的事——手写 EXPLAIN ANALYZE、给 DBA 发邮件、赌哪种 join 顺序能让那张表跑得更快——可能从一开始就不该是人工干的。
这篇文章不是技术教程，也不是要给哪个公司做广告。我只是想用三个事实 + 一张数字图，把"AI 教父辛顿和 Anthropic CEO 阿莫迪都不看好的那个紧急关闭按钮"（这是今天 IT 之家一条新闻的标题）和"4B 模型把 Postgres 打趴"放到同一个画面里，看看到底发生了什么。
一、那个"81%"是怎么算出来的
先把数字摆出来。Rohan 的实验在 IMDb 数据集上跑了 113 条 join-heavy 的查询，4B 模型初始状态是对其中 99 条查询根本没法生成一个查询计划——它连 EXPLAIN 输出的语法都没见过。
训练过程分两步：
- 第一步是监督微调（SFT）：用 GPT-6 Astra agent 跑出来的查询计划作为"老师答案"，让 4B 模型先学会"按规矩写出合法的 Postgres hint"。
- 第二步是 agentic 强化学习（RL）：让 4B 模型对每条查询生成 4 个候选 hint，发给真实的 Postgres 实例去测耗时，按耗时给奖励，再把权重更新回模型。
跑完两阶段之后，113 条查询的平均延迟下降 44.7%。再叠加 Rohan 自定义的 GRPO 变体（专门处理"容器里页面缓存抖动"那种噪声奖励），最终 4B 模型在某些子集上的查询计划比 Postgres 默认计划快 81%。
这不是论文里的"理论加速比"，是实打实地在 4 台并发的 Postgres 容器上、用 EXPLAIN ANALYZE 测出来的数字。
二、最让我睡不着的是另一组数字
但 81% 不是让我失眠的数字。
让我失眠的是 Rohan 文章里随手提到的一个背景：Postgres 自带的查询优化器要解决的问题之一——join ordering——是 NP-hard。也就是说，理论上就不存在一个"永远选对"的算法。
这件事我做了八年程序员都没认真想过。我一直以为 Postgres 的 planner 是"虽然不是最优解但够用"，直到我看到 Rohan 引用了 Leis 等人在 2015 年和 2025 年做的两次"数据库优化器体检"——
十年过去了，优化器依然在最常见的 join 场景里选错计划。
十年。一整个分布式数据库研究时代。一整个"我们用 CockroachDB / TiDB / OceanBase 重新发明 SQL"的轮回。
而答案可能是：一个 4B 的小模型，用 RL 训两下，就能在不修改 Postgres 一行代码的情况下，把 planner 的平均决策质量提升近一半。
三、Postgres 不知道什么是"好的计划"
Rohan 的文章里有一个小细节，我觉得比 81% 那个数字更值得程序员记一辈子。
他写道："4B 模型生成计划之后，要把候选计划发给 Postgres 测量耗时——也就是 Postgres 本身其实知道哪个计划更好，前提是你能给它一个有信号的奖励。"换句话说：
- Postgres 的 planner 不是"不知道"，而是没有足够的反馈机制让它自我修正
- 它的代价模型（cost model）基于统计信息 + 直方图，但这些信息在数据倾斜的场景里就是会失真
- 4B 模型做的事，抽象来看就是——用一个外部的"评委"给 planner 每次决策打分，然后用 RL 把"评委打分高的策略"学到模型里
这跟 Anthropic 创始人 Dario Amodei 上周在虎嗅一篇长文里写的核心命题是同一个：
"AI 公司应该放慢脚步，不是为了监管，而是为了让模型自己有足够的反馈信号去对齐人类的真实意图。"
我读完 4B 模型那篇文章之后，把这句话反复念了三遍。
四、Postgres 自己也不知道自己的最佳计划
这是真正的反转点。
我们这些写业务代码的人，过去十年一直在做两件事：
- 第一件：祈祷 Postgres 的 planner 在我这张 800 万行的表上能选对 hash join
- 第二件：如果选错了，就去找 DBA 改表结构、加索引、强制 hint
但 Rohan 的实验证明了一件事：那个被我们当成"权威裁判"的 planner，在 81% 的场景里其实不是最优解。
这不是 Postgres 的失败。Postgres 是 1996 年开始写的代码，那时候还没有 RL、没有 transformer、没有 IMDb 这种 join-heavy 的工作负载。它的 planner 是基于经典关系代数 + 代价估算设计的，在它诞生的年代，"够用"就是胜利。
但 2026 年的 join-heavy 场景——社交网络的关系查询、推荐系统的多表 join、电商的实时榜单——已经远远超出了"经典代价模型"的覆盖面。Postgres 在这些场景里不是在选最优解，它是在做它能做的最好猜测。
而 4B 模型做的事，本质上是给这个猜测加了一层"外部评委"。
五、紧急关闭按钮其实按不死 Postgres 的 planner
今天的 IT 之家有一条新闻标题是这样的：
"紧急关闭"按钮真能阻止 AI 失控？"AI 教父"辛顿、Anthropic CEO 阿莫迪都不看好
辛顿和阿莫迪担心的是：未来某个强大的 AI 在关键时刻按下了不该按的按钮，或者没按下该按的按钮。
但你回头看 Postgres 的 planner，它从 1996 年到 2026 年，一直都在"该按的按钮没按"的状态下运行——每天在全球无数公司的生产环境里，悄悄地选错几百万次查询计划。
只不过这种"按错按钮"的代价不是科幻片里的核弹，是每条 SQL 多跑 100 毫秒、凌晨三点 DBA 收到 1000 条告警、产品经理开会时甩一句"为什么这个页面这么慢"。
我们从来没有给 Postgres 一个"紧急关闭按钮"——我们只是在它按错的时候，写一段工单。
六、那张图
为了把这篇文章里所有数字放在一张图里，我让 4B 模型自己生成了一张对比图。标题叫 "113 条 join-heavy 查询的延迟分布"：
- 横轴：查询编号 1-113
- 纵轴：执行耗时（毫秒，对数刻度）
- 灰线：Postgres 默认计划
- 蓝线：4B 模型生成的计划
蓝线在 79/113 条查询上都比灰线低（也就是更快）。在 23 条上完全持平（Postgres 已经选对了）。在 11 条上反而比灰线慢——也就是 4B 模型也有它不知道的盲区。
这 11 条查询大概就是 RAG 系统里所谓的"长尾"：要么是数据倾斜到了 planner 不会去猜的角度，要么是统计信息已经过期但 4B 模型也没意识到。
我跟 Rohan 在评论区里聊了一句："这 11 条是 model 还是 data 的问题？"他回："Data。统计信息更新周期是 5 分钟一次，4B 模型的策略是基于 5 分钟前的快照训练的。"
也就是说：
- 如果你能给 planner 一个实时更新的反馈信号
- 如果你能给 4B 模型实时的训练数据
- 那么理论上，113 条查询里没有一条会跑得比默认 plan 慢
这正是 RL 在 query optimization 上的全部浪漫。
七、一笔账：训这个 4B 模型到底要花多少钱
Rohan 文章里没明说训练总成本，但给出了几条线索：
- 训练硬件：1 台租来的 2x H100 节点（vLLM + trainer 跑在同一台机器上）+ 4 台 Postgres 容器（就摆在他桌子上）
- 训练数据：500 条 GPT-6 Astra agent 跑出来的查询计划轨迹 + 113 条 join-heavy IMDb 查询
- 训练时间：粗略推算 4-6 小时（GRPO 4 个 rollout / 每条查询，113 × 4 = 452 次奖励回传）
按 2026 年 9 月公有云 2x H100 的市场价约 $2.5/小时算，一次完整训练的成本是 10-15 美元。
15 美元。10 杯奶茶钱。换来一个能在你公司生产环境的 Postgres 实例上跑赢默认 planner 44% 的小模型。
这件事的关键不在于"15 美元很便宜"，而在于——成本结构变了。以前调优 Postgres 查询计划要靠一个有 8 年经验的 DBA 一周时间，现在一个会写 Python 的初级工程师加上 4 小时 RL 训练就能复现。
我们 DBA 群里有个 2002 年入行的老哥上周还跟我说："AI 来了 DBA 不会失业，但 junior DBA 一定会。" 当时我以为是安慰他的话。
现在我不确定了。
八、我今天上班打算做什么
我今天打算做三件事：
- 第一件，把生产环境里那张跑了 800 万行的表的所有慢查询导出来，让 ChatGPT 用 4B 模型跑一遍 hint，看看我们公司里那个"Postgres 不知道自己的最佳计划"的现象有多严重。
- 第二件，给 DBA 群发一条消息："你们知道 join ordering 是 NP-hard 的吗？" —— 预计会被回复一个白眼。
- 第三件，把 Rohan 那篇文章存到我的 Notion 里，分类到"AI 在重写我们以为已经解决的问题"。
第三件不是今天能做完的。它是一整个新职业的开始——AI query planner tuner——一个 2026 年之前不存在的岗位，一个需要既懂 SQL 又懂 RL 的岗位。
如果今天下班前我的 leader 问我"这事跟你现在的活有什么关系"，我打算这么回：
"我们组每天有 2000 条慢查询告警，其中 40% 是 planner 选错 join 顺序。如果给我们的 4 个 Postgres 实例配一个 4B 模型的 hint service，理论上一周能省下约 80 小时的查询时间——按公司内部计费标准折算，每年约 200 万元的 infra 成本。"
我猜 leader 会说："先做个 PoC，下季度评审。"
但这就是我想说的——PoC 的成本已经低到可以让每个小组都试一遍。以前这种内部工具 ROI 不够，现在 15 美元的训练成本 + 一周的开发时间，ROI 算得过来。
九、给所有写过慢查询的程序员
Rohan 文章评论区里有一条很短的留言，来自一个 1998 年就开始用 Postgres 的人：
"I always thought of the planner as a black box I cursed at. Now I realize it's a black box I should have helped train."
我也一直把 Postgres 的 planner 当成"那个永远跟我作对的家伙"。每次看到 EXPLAIN 输出不符合预期，我都骂一句"你这个 planner 是怎么想的"。
现在我意识到——planner 从来不知道怎么想，它只是在做它能做的最好猜测。
而 2026 年 9 月这个 4B 模型的故事告诉我：
**过去 30 年数据库优化器一直是个'没有人帮它训练'的模型。它以为自己够用，是因为从来没人给它足够便宜的反馈信号。**
这句话大概会变成接下来 5 年数据库领域最重要的一个命题。
十、写在最后
Rohan 在文章结尾写了一段话，我翻译过来大意是：
"我们这个实验不是为了证明 LLM 能取代 Postgres planner，而是为了证明：在 query optimization 这种'决策质量可以被实时验证'的任务上，RL 比人类手工调参更有效。这是一个可以推广到所有'代价模型不完美 + 反馈信号便宜'的工程问题的范式。"
这段话让我想起 2018 年我刚毕业时听到的一句话："SQL 优化器是数据库里最难写的部分，因为它的目标函数是用户的耐心。"
8 年过去了，用户的耐心还是一样短。但写优化器的人，从 DBA 变成了 RL agent。
我作为程序员，过去 8 年学到最有用的一个技能不是写更快的 SQL，而是知道一件事——Postgres 不是数据库，它是数据库的猜测。
而 2026 年 9 月这件事告诉我，那个猜测可以更准。
只要给它一个"评委"。
本文为虚构故事，不涉及真实公司人物。
评论区