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”到底是什么意思这个项目叫做QORLQuery 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。换算成 speedup1 / 0.553 ≈ 1.81于是就有了1.81x 81% faster所以“快 81%”这个说法数学上没有错。但它更像是Hacker News 标题语言而不是作者原文中的实验结论表达。二、真正重要的不是 81%而是它的测试条件如果只记住“4B 模型比 PostgreSQL 快 81%”其实会严重误解这个实验。真正需要关注的是下面几个条件。1. 测试的不是普通业务 SQLQORL 使用的是JOBJoin Order Benchmark数据集来自IMDb一共测试113 个查询而 JOB 本身就是一个专门用来考验数据库多表 Join Order Optimization能力的 Benchmark。这些 SQL 往往具有大量表连接复杂 Join 顺序分析型查询对基数估计非常敏感所以这个结果不能简单理解成“以后你系统里的所有 SQLAI 都能优化快 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 LoopPlan ↓ Execute ↓ Measure ↓ Adjust ↓ Plan Again这也是我认为这个项目真正值得看的地方。四、为什么 PostgreSQL 优化器会输想理解这个实验为什么有效就需要先理解一个数据库里非常经典的问题Join Ordering假设有A B C D E5 张表需要连接。数据库可以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中的HistogramMost Common ValuesDistinct ValuesNull 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 ModelOptimizer 内部原理它只需要不断做一件事情试。然后数据库负责告诉它这个方案到底快不快。作者有一句话很好地总结了这个特点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配置主从复制让复制流量走内网配置从库拒绝写入自己分析安装和配置过程中的错误一共测试了多个模型包括QwenKimiDeepSeekGLMGemma等等。实验结果里有几个地方特别值得注意。第一小模型已经可以完成相当复杂的 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 dont 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验证器。它们需要理解业务优先级数据重要程度SLARPO / 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 SQLBI 查询大型分析 SQL每天重复执行的大查询也就是Offline Search Online Execution我认为这甚至可能成为一个非常实际的数据库工程方向。3. 给 AI Agent 数据库权限之前先设计 Guardrailsdbaai_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 已经可以闭环完成相当复杂的真实数据库运维任务。而且这里还有一个很值得注意的趋势模型不一定越大越好。对于很多专业 AgentSmall Model Tool Use Environment Feedback Verifier RL可能比单纯继续堆模型参数更加重要。所以如果问AI 能当 DBA 了吗我的答案不是AI 马上要把 DBA 取代了。而更接近它已经可以成为一个非常勤奋的 Junior DBA。它不知疲倦愿意反复试错能快速执行大量技术动作。但涉及真正的生产决策时Senior 还是得坐在旁边。至少短期内数据库运维真正难以交出去的并不是How to execute?而是Should we execute?而对于 DBA 和数据工程师来说现在最值得做的事情也许不是讨论AI 会不会取代我而是开始考虑哪些原本靠人工不断试错的工作可以先交给 Agent因为真正正在快速下降的并不是 DBA 的价值。而是“试错”的成本。ReferencesQORL 原始技术文档Rohan BansalTraining a 4B model to produce 81% faster query plans than Postgres - Rohan BansalQORL GitHub RepositoryGitHub - polyphilz/qorl: Query optimization via agentic reinforcement learning · GitHubEvaluating LLM Models for DBA TasksVadim Tkachenko, PerconaEvaluating LLM models for DBA tasks - PerconaA 4B Model Just Beat Postgress Query Planner by 81%Vin PatelA 4B Model Just Beat Postgress Query Planner by 81% · Vin Patel