让 40 亿参数的模型改写查询计划：数据库优化器正在被重新定义

查询优化器：数据库里最难啃的一块骨头

同一句 SQL，换个连接顺序、换个索引，执行时间可能相差几十倍。这件事长期靠两样东西兜着：优化器里写死的代价模型，以及资深 DBA 的直觉。代价模型遇到数据分布倾斜、多表关联复杂时经常估算失准，而好 DBA 昂贵且难以复制。于是“慢查询”成了运维工单里出现频率一直下不来的一类问题。

近期一项公开实验提供了新思路：训练一个约 40 亿参数的小模型，专门为查询生成执行计划，在测试集上产出的方案比 PostgreSQL 默认优化器更快。值得注意的是它的定位——模型并不替换数据库，而是替换“调优决策”这一步：输入表结构、统计信息与 SQL 语句，输出执行计划，模型学的是老手看执行计划时的那点判断力。

对产业侧的三点现实意义

一，经验第一次可以打包迁移。大多数中小企业的系统并非没有性能问题，而是没人有时间逐条调优。若这类能力能以插件形式部署，等于把稀缺的 DBA 判断力变成了可分发的基础设施。

二，小模型是更务实的落点。40 亿参数意味着它有机会在单卡甚至边缘设备上跑，不必把生产环境的表结构与 SQL 发往外部服务。数据不出内网这件事，在政企和产业客户的采购决策里，权重往往高于几个百分点的性能提升。

三，代价是新的不可解释性。优化器的估算逻辑再差，至少能被人读懂、被人改写；模型给出的计划为什么更好，多数时候说不清。而在生产环境里，“说不清”意味着出事时难以定位。

别急着把它当银弹

这类方案要真进生产，还差三件东西：可回滚——模型给出的计划必须能一键退回原优化器；可观测——每次决策要留下输入与依据；可约束——明确禁止生成全表扫描一类的高代价操作。技术选型的判断标准其实很简单：它不是让你换掉数据库，而是让你在没人调优的时候，系统也能自己应付过去。对多数产业团队而言，这个价值已经足够实在。