从软件开发到 AI Systems：一次 PostgreSQL 学习型查询优化研究实践

写在前面本科毕业一年已经经历了一轮大厂实习-大厂入职-离职 的流程其中心路历程以后有机会写。目前在探索AI Systems学术路线所以这篇内容可以定位为本科生/程序员 转AI Systems科研路线的第一次研究实践。考虑到之前的工作经常和数据库打交道于是打算从database 来切入AI Systems 领域的研究。研究总览为什么值得研究一条SQL如何被Optimizer优化器处理什么是Optimizer简单来说数据库面对一条 SQL并不是直接执行而是先尝试设计一条“执行路线”。这个设计过程就是由Optimizer来完成SQL | v Optimizer选择执行方式 | v Execution Plan执行方案 | v Runtime实际耗时但优化器并不知道真实运行时间它只能根据内部成本模型预测哪种方案更快。它不是神并不能每次都估计对有时候Optimizer认为 Plan A 快 实际 Plan B 快问题来了能不能让机器学习帮它重新选择一张图讲清楚研究PostgreSQL | Candidate Plans | ----------------- | | XGBoost GNN (Tabular) (Graph) | | ----------------- | Better Plan Selection没有替换数据库Optimizer的成本估计模型。而是给数据库生成的候选方案重新排序。实验中几个有意思的发现更复杂的模型不一定更强。很多人认为图神经网络理解结构所以一定更好。但是实验发现一个强大的表格模型已经捕获大量信息这些信息足够让它在多数情况下做出最优解。但是复杂模型不是没用有趣的是GNN虽然整体较弱但它和XGBoost做出的判断并不完全一样。而且实验发现当 SQL 查询包含更多表连接、更复杂的执行结构时GNN 和 XGBoost 的表现差距逐渐缩小。说明复杂模型可能捕获了传统特征难以表达的信息。AI系统真正难的是选择问题不是哪个模型绝对更强而是什么时候应该相信哪个模型。项目完整代码本篇文章主要介绍的是宏观上的东西比如流程、主要洞察。但实际实验中有大量细节处理和实验方法比如如何让数据库生成尽可能多且丰富的执行计划执行计划如何打标签怎么把执行计划转成模型需要的“表示”怎么用 实验证明“互补信息”各种失败的实验踩的坑······这些都在项目的 GitHub 仓库如果对你有一些启发欢迎 star~项目完整代码实验如果你也对 AI Systems、数据库或者科研型项目感兴趣欢迎交流。另外这个项目也整理成了一篇 research paper draft发布在 arXiv。如果你想了解更完整的实验细节可以查看论文版本。