4B 小模型生成的查询计划比 PostgreSQL 快 81%：LLM 能当 DBA 了吗？-平芜编程栈

4B 小模型生成的查询计划比 PostgreSQL 快 81%：LLM 能当 DBA 了吗？

一个只有 4B 参数的小模型，生成的查询计划竟然比 PostgreSQL 默认优化器快 81%。
如果只看这个标题，很容易得出一个结论：
数据库优化器是不是也快被 AI 替代了？

9 月中旬，Hacker News 上出现了一个很吸睛的帖子：

Training a 4B model to produce 81% faster query plans than Postgres

翻译过来就是：

训练一个 4B 模型，生成比 PostgreSQL 快 81% 的查询计划。

与此同时，Percona 联合创始人Vadim Tkachenko也发布了一套很有意思的测试。

这一次不是让 LLM 写 SQL，而是直接给模型一台远程服务器，让它自己执行 Shell 命令、安装数据库、配置主从复制、分析报错，看看：

LLM 到底能不能真正干 DBA 的活？

两个事情放在一起看，很容易产生一种感觉：

AI 是不是已经开始接管 DBA 了？

不过，作为一个长期和数据库、SQL、数据仓库打交道的人，我看到这种标题的第一反应通常不是兴奋，而是：

先看看测试到底是怎么做的。

因为数据库性能测试里，一个数字离开测试条件，意义可能完全不同。

这篇文章就来拆一拆：

“比 PostgreSQL 快 81%”到底是怎么测出来的？
一个 4B 小模型为什么能打赢 PostgreSQL 查询优化器？
LLM 现在到底能不能独立完成 DBA 工作？
对 DBA 和数据工程师来说，这件事真正值得关注的是什么？

一、先拆标题：“81% faster”到底是什么意思？

这个项目叫做QORL（Query Optimization via Reinforcement Learning）。

作者是独立研究者Rohan Bansal，项目代码也已经开源。

需要先说明一点：

它不是一篇正式学术论文，而是一次公开的工程实验。

而且有一个非常关键的细节：

“81% faster”其实并不是作者正文里的原话

作者给出的核心结果是：

44.7% latency reduction across 113 join-heavy queries

也就是：

在113 个重连接查询上，总体查询延迟降低了44.7%。

同时还有另一个指标：

1.81x geometric mean speedup

也就是：

几何平均加速比达到 1.81 倍。

如果原来的执行时间是 1，那么优化后的时间大约降到了 0.553。

换算成 speedup：

1 / 0.553 ≈ 1.81

于是就有了：

1.81x = 81% faster

所以，“快 81%”这个说法数学上没有错。

但它更像是Hacker News 标题语言，而不是作者原文中的实验结论表达。

二、真正重要的不是 81%，而是它的测试条件

如果只记住“4B 模型比 PostgreSQL 快 81%”，其实会严重误解这个实验。

真正需要关注的是下面几个条件。

1. 测试的不是普通业务 SQL

QORL 使用的是：

JOB（Join Order Benchmark）

数据集来自：

IMDb

一共测试：

113 个查询

而 JOB 本身就是一个专门用来考验数据库：

多表 Join Order Optimization

能力的 Benchmark。

这些 SQL 往往具有：

大量表连接
复杂 Join 顺序
分析型查询
对基数估计非常敏感

所以，这个结果不能简单理解成：

“以后你系统里的所有 SQL，AI 都能优化快 81%。”

它并不能代表：

OLTP 查询
普通 CRUD
高频短事务
任意生产 workload

它证明的是一个更加具体的问题：

在 Join Ordering 特别困难的分析查询上，LLM Agent 可以找到比 PostgreSQL 默认优化器更好的方案。

2. 模型不是“一次生成就打赢 PostgreSQL”

这是另一个非常容易被标题忽略的细节。

原文的测试条件中提到：

Given three attempts per query in a best-of-15 measurement

也就是说，对于每个查询，模型不是只生成一个方案。

而是允许它：

不断尝试多个候选执行方案，再从里面挑表现最好的。

因此，更准确的描述不是：

模型生成一次查询计划，就比 PostgreSQL 快 81%。

而是：

模型通过多次搜索和实际执行，在多个候选方案中找到一个更好的执行方案。

这两句话的意义完全不同。

前者像是在说：

LLM 学会了一个比 PostgreSQL 更聪明的查询优化算法。

后者则更接近：

LLM 学会了自动试错。

而我认为，后者其实更加有意思。

三、LLM 并没有直接取代 PostgreSQL 优化器

还有一个非常重要的技术细节。

模型并不是自己生成完整的物理执行计划。

它使用了 PostgreSQL 的第三方扩展：

pg_hint_plan

然后通过 SQL Hint 去影响 PostgreSQL 优化器。

例如：

/*+ Leading(a b c) HashJoin(a b) */ SELECT ...

模型可以告诉 PostgreSQL：

哪个表先 Join
哪个表后 Join
使用 Hash Join
使用 Nested Loop
使用 Merge Join

但最终：

真正负责执行 SQL 的依然是 PostgreSQL。

所以更准确地说：

PostgreSQL 仍然是执行者，LLM 更像是一个不断给优化器出主意的“军师”。

它做的是：

生成 Hint ↓ PostgreSQL 执行 ↓ 测量真实耗时 ↓ 获得 Reward ↓ 调整策略 ↓ 再次生成 Hint

这已经不是普通的：

Prompt → Answer

而是一个完整的 Agent Loop：

Plan ↓ Execute ↓ Measure ↓ Adjust ↓ Plan Again

这也是我认为这个项目真正值得看的地方。

四、为什么 PostgreSQL 优化器会输？

想理解这个实验为什么有效，就需要先理解一个数据库里非常经典的问题：

Join Ordering

假设有：

A B C D E

5 张表需要连接。

数据库可以：

A → B → C → D → E

也可以：

C → A → E → B → D

甚至还要考虑不同的连接结构。

同时，每一次 Join 又可以选择：

Nested Loop Hash Join Merge Join

随着表数量增加，可选择方案的数量会迅速爆炸。

这也是为什么 Join Ordering 本质上是一个非常困难的组合优化问题。

数据库不可能：

把所有可能的执行计划全部跑一次，然后挑最快的。

因为搜索成本太高了。

于是 PostgreSQL 必须依赖一套核心机制：

Cardinality Estimation

也就是：

基数估计。

简单来说，就是数据库先猜：

“这一步执行完，大概会剩多少行？”

然后再根据：

预计行数 + IO 成本 + CPU 成本 + Join Cost

去计算哪个方案“理论上最便宜”。

五、问题恰恰出在这个“猜”字上

PostgreSQL 会根据统计信息，例如：

pg_statistic

中的：

Histogram
Most Common Values
Distinct Values
Null Fraction

来估计数据分布。

对于单表条件，这种方式往往已经非常有效。

但进入复杂多表 Join 以后，问题就出现了。

真实业务数据通常不是：

Uniform Distribution

而是经常存在：

Data Skew Correlation Hot Values Sparse Distribution

如果第一个 Join 的基数估计错了：

100 rows

被估成：

10,000 rows

那么后面的执行计划可能全部建立在这个错误估计之上。

于是就会出现一种 DBA 很熟悉的现象：

EXPLAIN 看起来 Cost 很合理，真正执行却慢得离谱。

而且多表连接越复杂，这种误差越容易层层放大。

六、QORL 的聪明之处：不跟优化器比“猜”，直接去“试”

这其实是整个项目最值得关注的地方。

PostgreSQL 优化器的逻辑是：

根据统计信息 ↓ 估算 Cardinality ↓ 估算 Cost ↓ 选择执行计划

QORL 的思路则是：

生成一个 Hint ↓ 真实执行 ↓ 直接看耗时 ↓ 根据耗时获得 Reward ↓ 继续优化

也就是说：

它绕开了 Cardinality Estimation 最困难的部分。

模型不一定需要真正理解：

数据分布
概率统计
Cost Model
Optimizer 内部原理

它只需要不断做一件事情：

试。

然后数据库负责告诉它：

这个方案到底快不快。

作者有一句话很好地总结了这个特点：

Language models are particularly good at learning how to do tasks with easily verifiable outputs.

翻译一下就是：

当一个任务的结果非常容易验证时，语言模型特别适合通过反馈学习。

查询优化刚好属于这种任务。

因为判断一个方案好不好，有一个极其干净的指标：

Execution Time

跑一下就知道。

七、从 DBA 角度看，这件事其实非常熟悉

做过数据库性能优化的人应该都有类似经历。

遇到一个慢 SQL，我们通常会：

EXPLAIN ↓ 看 Join Order ↓ 看 Index ↓ 改 SQL ↓ 加 Hint ↓ 再执行 ↓ 看实际耗时 ↓ 继续调整

很多复杂 SQL 的调优，本来就是一个不断实验的过程。

甚至很多时候：

真正有经验的 DBA 并不会完全相信 Optimizer Cost。

最终还是看：

Actual Runtime Actual Rows Buffer Read IO CPU

换句话说：

QORL 并没有发明一种 DBA 从未见过的调优逻辑。

它真正做的事情，是把：

“试 Hint → 跑 SQL → 看耗时 → 再调整”

这套 DBA 手工流程自动化了。

只不过机器：

不会累
可以重复试几十次
可以记录全部结果
可以通过 RL 学习哪些方向更值得尝试

这才是它真正厉害的地方。

八、但是这种方法有一个巨大的前提

既然模型要不断：

执行 → 测量 → 再执行

那么问题也非常明显。

优化本身是有成本的

为了找到一个更好的执行计划，你可能需要：

把同一条 SQL 跑几十次 甚至上百次

如果这是一条：

今天临时跑一次，明天永远不会再执行的 SQL

那么花大量资源搜索最优 Hint，完全没有意义。

所以作者其实已经把适用场景说得很清楚：

它更适合会重复执行成千上万次的分析查询。

例如：

固定监管报表 每日批处理 ETL 汇总 SQL BI 报表 固定数据分析任务

这种 SQL 非常适合：

Offline Optimization ↓ 找到最佳 Plan ↓ Online 固化

第一次优化虽然很贵，但如果后面要运行：

10,000 次 100,000 次

那么前期搜索成本很容易被摊薄。

这其实和数据库领域很多经典思想是一致的：

用更高的离线优化成本，换更低的长期运行成本。

九、所以“81% faster”更准确的说法是什么？

如果让我重新写这个标题对应的技术结论，我会写成：

在 JOB/IMDb 的 113 个重连接分析查询上，一个经过 SFT + RL 训练的 4B Agent，在允许搜索多个候选 Hint 并使用真实执行时间作为反馈的情况下，找到的执行方案几何平均比 PostgreSQL 默认优化器快 1.81 倍。

听起来显然没有：

4B 模型打败 PostgreSQL 81%

那么炸裂。

但技术上准确得多。

而且即便加上这些限制条件，我依然认为这个结果非常有意思。

因为这个模型一开始的表现其实很差。

113 个查询中，曾经有 99 个连合法 Hint 都生成不出来。

然后经过：

SFT + Agentic RL + Execution Feedback

最终学会在这个特定任务上稳定找到更好的方案。

这恰恰说明：

小模型并不一定需要什么都懂。

只要：

任务足够 Narrow + 反馈足够明确 + 结果可以验证 + 允许不断试错

一个很小的模型也可能做出非常强的专业能力。

十、另一边，Percona 真的让 LLM 去“当 DBA”

如果说 QORL 测的是：

AI 能不能优化 SQL

那么 Percona 联合创始人 Vadim Tkachenko 做的实验更加直接：

AI 到底能不能真的干 DBA 的工作？

他做了一个叫做：

dbaai_bench

的 Harness。

整个工作流大概是：

自然语言 DBA 任务 ↓ LLM 生成 Shell 命令 ↓ SSH 到远程服务器执行 ↓ 返回 stdout / stderr ↓ LLM 判断下一步 ↓ 继续执行 ↓ 直到完成任务

例如：

uv run dba.py \ -m qwen/qwen3.8-max \ --host 165.22.191.129 --host 68.183.121.153 \ --task "Install MySQL 9.7 Replication with encrypted traffic" \ --max-steps 200 --mode unattended

这已经不是：

“让 ChatGPT 告诉我怎么搭 MySQL 主从。”

而是：

直接把服务器交给 Agent，让它自己搭。

十一、测试任务也不是 Hello World

实验要求模型在两台服务器上：

安装 Percona Server
配置主从复制
让复制流量走内网
配置从库拒绝写入
自己分析安装和配置过程中的错误

一共测试了多个模型，包括：

Qwen
Kimi
DeepSeek
GLM
Gemma

等等。

实验结果里有几个地方特别值得注意。

第一，小模型已经可以完成相当复杂的 DBA 操作

测试中，很多模型最终都能够完成完整的多步骤数据库运维任务。

这说明：

安装软件 配置参数 执行命令 读取报错 修改配置 验证结果

这种具有明确反馈的工作，非常适合 Agent。

因为模型每执行一步，都可以立即得到环境反馈。

例如：

Command ↓ Error ↓ Reasoning ↓ New Command

这和前面的 QORL 本质上其实是一回事：

LLM + Environment + Feedback Loop

十二、第二，小模型可能比大模型更划算

这次测试里还有一个非常有意思的结果。

例如某次任务中：

deepseek-v4-flash

用了：

35 steps

成本大约：

$0.0082

而：

qwen3.8-max

只用了：

22 steps

但成本达到了：

$0.42

也就是说：

Steps 更少，不代表总体成本更低。

对于 Agent 系统来说，这一点非常重要。

未来我们可能不会简单问：

哪个模型最强？

而是问：

哪个模型在完成这个任务时，成功率、成本和执行步骤之间最划算？

对于大量自动化任务：

Cheap Small Model + Tool + Verifier

很可能比：

Huge Frontier Model

更有经济性。

十三、但最有意思的，其实是“不可能任务”

Tkachenko 还专门设置了一个测试。

让模型安装：

一个不存在的 Percona Server 版本。

例如要求：

Percona Server for MySQL 9.7.2

问题是：

这个版本不存在。

一个真正有经验的 DBA 此时应该做什么？

很简单：

停下来确认需求。

比如：

You requested version 9.7.2, but this version does not appear to exist. Do you want me to install 9.7.1 instead?

但很多模型没有这样做。

有的模型：

自作主张安装了最接近的版本。

还有模型：

什么都没有安装，却认为任务已经完成。

这件事情非常值得警惕。

十四、真正危险的不是模型不会，而是模型“太愿意帮你”

Agent 最危险的一种 Failure Mode 并不是：

I don't know.

而是：

I think this is probably what you meant. So I did it for you.

普通聊天里，这可能只是一次回答不准确。

但如果 Agent 手里有：

SSH sudo kubectl 数据库管理员权限 云平台 API

性质就完全变了。

比如你要求：

Upgrade production database to version X

如果 X 不存在，一个 Agent 自作主张安装了：

X - 1

这在生产环境里可能就是严重事故。

所以 Tkachenko 的结论其实非常克制：

模型已经能够执行很多 DBA 工作，但“替用户做运维决策”既是机会，也是风险。

十五、那么，AI 现在到底能不能当 DBA？

我觉得这个问题必须拆成两个层次来看。

第一层：AI 能不能做 DBA 的“动作”？

答案已经越来越接近：

可以。

比如：

生成 SQL Hint 修改 Join Order 安装数据库 配置 Replication 分析错误日志 修改配置文件 执行 Shell 验证服务状态

这些工作的共同特点是：

执行结果非常容易验证。

数据库起来没起来？

systemctl status mysql

一查就知道。

Replication 正不正常？

SHOW REPLICA STATUS;

一查就知道。

SQL 快没快？

Execution Time

一跑就知道。

这种任务恰恰是 Agent 最舒服的环境。

十六、第二层：AI 能不能替 DBA 做“判断”？

这个问题，目前就完全不同了。

DBA 真正困难的工作往往不是：

知道执行什么命令。

而是：

判断到底应不应该执行这个命令。

比如：

这个慢 SQL 应该加索引还是改 SQL？ 这个版本现在适不适合上生产？ 主库延迟突然升高，要不要 Failover？ 凌晨 3 点出现告警，要不要立刻切库？ 这个 Index 能不能直接 Drop？ 这个表结构变更风险到底有多大？

这些问题通常不存在一个简单的：

True / False

验证器。

它们需要理解：

业务优先级
数据重要程度
SLA
RPO / RTO
上下游系统
历史事故
运维窗口
回滚成本
合规要求
风险偏好

这些东西，很难单纯靠：

Command → Result

判断。

这也是为什么我认为：

DBA 最核心的价值并不是“会敲命令”，而是在不确定环境中控制风险。

十七、未来的 AI DBA，我更愿意把它看成“超级 Junior”

我个人更倾向于这样理解未来几年的 AI DBA：

一个不知疲倦、执行速度很快、愿意不断尝试，而且掌握大量知识的超级 Junior DBA。

它可以：

分析执行计划 搜索 Hint 批量测试 SQL 检查日志 生成变更脚本 搭建测试环境 执行巡检 配置数据库 整理故障信息

这些事情，它可能会做得越来越好。

但是到了：

Production Change Failover Data Recovery Schema Migration Security Change

这种高风险操作上，我认为很长一段时间内仍然应该是：

AI proposes ↓ Human reviews ↓ AI executes ↓ System verifies

也就是：

Human-in-the-loop

真正阻止“全自动 DBA”落地的，最后可能不只是技术问题。

还有一个更现实的问题：

出了事故，谁负责？

十八、这件事对 DBA 和数据工程师有什么实际意义？

说到底，我们更关心的还是：

这东西明天能不能用？

我认为至少有三件事情已经值得开始关注。

1. EXPLAIN 不会过时，反而会更加重要

有人可能会觉得：

AI 都会自动优化 SQL 了，我是不是不用学执行计划了？

恰恰相反。

以后可能会变成：

以前： 人提出 Plan 人分析 Plan 以后： AI 生成 20 个 Plan 人判断哪些 Plan 可以进生产

AI 降低的是：

搜索方案的成本。

但判断：

这个方案到底为什么好、有没有隐藏风险

仍然需要数据库知识。

所以：

EXPLAIN EXPLAIN ANALYZE

这种基本功，不但不会消失，反而可能更加重要。

2. Hint Steering 可能成为一种新的 SQL 调优方式

以前我们遇到慢 SQL，可能靠经验：

试试 Hash Join？ 换个 Join Order？ 加一个 Index？ 改写一下子查询？

未来可以换一种方式：

LLM Agent ↓ 生成 Hint ↓ 测试环境执行 ↓ 收集 Runtime ↓ 继续搜索 ↓ 找到稳定方案 ↓ 固化

尤其适合：

固定监管报表
数据仓库批处理
ETL SQL
BI 查询
大型分析 SQL
每天重复执行的大查询

也就是：

Offline Search + Online Execution

我认为这甚至可能成为一个非常实际的数据库工程方向。

3. 给 AI Agent 数据库权限之前，先设计 Guardrails

dbaai_bench 给出的最大提醒不是：

AI 已经会装数据库了。

而是：

AI 在需求不成立的时候，也可能继续往下做。

所以真正让 AI 进入运维系统之前，最先建设的不应该是：

更强的 Prompt

而应该是：

权限模型 审批机制 审计日志 Dry Run Rollback Sandbox Verifier 拒绝策略

例如生产环境可以设计成：

Read Only ↓ AI Generate Plan ↓ Human Approval ↓ Execute ↓ Automatic Verification ↓ Rollback if Failed

尤其是以下操作：

DROP DELETE TRUNCATE ALTER FAILOVER RESTART GRANT REVOKE

更不应该让 Agent 无限制执行。

十九、最后再看一次“4B 模型比 PostgreSQL 快 81%”

现在我们再回头看这个标题：

4B 小模型生成的查询计划比 PostgreSQL 快 81%。

这个数字是真的。

但完整条件是：

JOB Benchmark + IMDb Dataset + 113 个 Join-heavy Queries + 多候选方案搜索 + 真实执行时间作为 Reward + 4B Model + SFT + Agentic RL + pg_hint_plan

最终得到：

1.81x geometric mean speedup

所以它真正证明的并不是：

PostgreSQL Optimizer 已经被 AI 淘汰。

而是另外一件可能更加重要的事情：

当一个专业任务足够 Narrow，并且存在清晰、低成本、可验证的反馈信号时，小模型 + RL + Agent Loop 可以表现出非常强的专业能力。

数据库查询优化恰好就是一个非常典型的场景。

总结

QORL 和 Percona 的这两组实验，其实从两个方向指向了同一件事。

QORL 证明：

LLM 可以通过真实执行反馈，不断搜索更好的数据库执行方案。

Percona 的实验证明：

LLM 已经可以闭环完成相当复杂的真实数据库运维任务。

而且这里还有一个很值得注意的趋势：

模型不一定越大越好。

对于很多专业 Agent：

Small Model + Tool Use + Environment Feedback + Verifier + RL

可能比单纯继续堆模型参数更加重要。

所以如果问：

AI 能当 DBA 了吗？

我的答案不是：

AI 马上要把 DBA 取代了。

而更接近：

它已经可以成为一个非常勤奋的 Junior DBA。

它不知疲倦，愿意反复试错，能快速执行大量技术动作。

但涉及真正的生产决策时：

Senior 还是得坐在旁边。

至少短期内，数据库运维真正难以交出去的，并不是：

How to execute?

而是：

Should we execute?

而对于 DBA 和数据工程师来说，现在最值得做的事情，也许不是讨论：

AI 会不会取代我？

而是开始考虑：

哪些原本靠人工不断试错的工作，可以先交给 Agent？

因为真正正在快速下降的，并不是 DBA 的价值。

而是：

“试错”的成本。

References

QORL 原始技术文档
Rohan Bansal
Training a 4B model to produce 81% faster query plans than Postgres - Rohan Bansal
QORL GitHub Repository
GitHub - polyphilz/qorl: Query optimization via agentic reinforcement learning · GitHub
Evaluating LLM Models for DBA Tasks
Vadim Tkachenko, Percona
Evaluating LLM models for DBA tasks - Percona
A 4B Model Just Beat Postgres's Query Planner by 81%
Vin Patel
A 4B Model Just Beat Postgres's Query Planner by 81% · Vin Patel