当 LLM 成为数据库的内生力量：从查询优化到内核开发
本期聚焦 LLM 深度嵌入数据库系统的五个前沿方向——用 MCTS 合成训练数据赋能小模型 SQL 重写、LLM 自动化数据库研究范式、数据库内核函数的 AI 合成、缺失值的概率查询语义、以及推断感知的隐私删除。
今日精选
LLM 与数据库的融合正在进入”内生化”阶段。过去我们讨论的是 LLM 如何帮助用户写 SQL（Text-to-SQL），今天的五篇论文揭示了一个更深层的趋势：LLM 正在成为数据库系统自身进化的驱动力——从自动发现更优的查询重写策略、到自主合成内核函数、再到重新定义数据删除的隐私语义。这不是”给数据库加个 AI 接口”的表面文章，而是从训练数据构建、系统架构搜索、到基础理论的全栈变革。
1. LASER：用 MCTS 造数据、用 GRPO 练小模型的 SQL 重写新范式
作者：Jiahui Li, Tongwang Wu, Yuren Mao, Rong Kang, Tieying Zhang, Yunjun Gao | 机构：浙江大学 · 字节跳动 发表时间：2026-04-08（arXiv 提交） 链接：arXiv · PDF · Code · Model
核心发现：
SQL 查询重写是数据库优化的经典问题。规则引擎（如 Calcite）缺乏适应性，直接用 GPT-4 级别的 LLM 做重写则面临推理成本和隐私风险。LASER 的核心洞察是：与其纠结于模型大小，不如在数据上下功夫——用高质量的合成训练数据把 8B 参数的小模型练成 SQL 优化专家。
数据构建采用了 SQL-MCTS（蒙特卡洛树搜索）策略：以真实慢查询为种子，通过规则引导的反模式注入（如不必要的子查询嵌套、冗余 JOIN）和 LLM 变异两条路径进行树搜索扩展，每个节点都经过实际执行验证，确保生成的慢查询确实”慢”且语义正确。这套方法构建出了一个规模和多样性远超现有基准的复杂慢查询语料库。
训练阶段提出了 SQL-GRPO，从 Group Relative Policy Optimization 改编而来。两个关键设计：一是”锚定组优势”——以原始慢查询的执行时间作为基准锚点来计算相对优势，避免奖励信号的漂移；二是”复杂性自适应动态展开”——对简单查询少做探索，对复杂查询分配更多 rollout 预算。最终在 Qwen3-8B 上实现，零样本迁移到未见过的数据库和 workload 上依然有效。
对数据工作的启示：
这篇论文是”以数据为中心”理念在数据库优化领域的标杆示范。MCTS + 执行验证的合成数据构建方法值得所有做数据驱动优化的团队学习：不要只靠模板和规则造数据，用搜索算法在结构空间中系统性探索，同时用真实执行作为质量守门人。对于内部有 DBA 团队的公司，可以考虑收集线上慢查询作为种子，用类似方法构建自己的 SQL 优化训练集。
2. AI-Driven Research for Databases：让 LLM 自动发现数据库算法
作者：Audrey Cheng, Harald Ng, Aaron Kabcenell, Peter Bailis, Matei Zaharia, Lin Ma, Xiao Shi, Ion Stoica | 机构：UC Berkeley · Meta 发表时间：2026-04-08（arXiv 提交） 链接：arXiv · PDF
核心发现：
如果说 LASER 是用 LLM 做”已知问题的更好解法”，这篇论文的野心更大：让 LLM 自己发现新的数据库算法。论文提出了 ADRS（AI-Driven Research for Systems）框架，将数据库优化从”人设计方案 → 人评估效果”转变为”LLM 生成候选方案 → 自动评估器筛选”的闭环。
关键瓶颈在评估端。LLM 可以一次生成数百个候选方案，但数据库系统的评估极其复杂——你不可能对每个方案都跑完整的端到端测试。论文的核心创新是评估器与解决方案的共同进化：评估器本身也是 LLM 生成的程序，随着对解决方案的测试经验积累而不断改进。
三个案例研究展示了这种方法的威力：在缓冲区管理中发现了优于 LRU-K 变体的新策略；在查询重写中找到了一种确定性策略，延迟降低最高达 6.8 倍；在索引选择中也超越了现有启发式方法。值得注意的是，这些并非对已有算法的微调，而是结构上全新的方案。
对数据工作的启示：
Ion Stoica 团队（Spark 和 Ray 的创造者）押注”AI 做系统研究”不是偶然。这预示着数据系统优化的范式转变：未来的 DBA 工具可能不再是”给你推荐索引”，而是”给你发现一个你的 workload 专用的新缓冲策略”。短期可落地的是：用 LLM 生成 + 自动评估的模式来做配置搜索——比如连接池大小、分区策略、物化视图选择等，这些都是评估成本可控的优化场景。
3. DBCooker：LLM 自动合成数据库内核函数
作者：Wei Zhou, Xuanhe Zhou, Qikang He, Guoliang Li, Bingsheng He, Quanqing Xu, Fan Wu | 机构：清华大学 · 新加坡国立大学 发表时间：2026-04-02（arXiv 提交） 链接：arXiv · PDF · Code · Project
核心发现：
数据库内核中的原生函数（如字符串处理、JSON 操作、地理空间计算）数量持续膨胀。仅 PostgreSQL 就有数千个内置函数，每次业务迁移或新应用接入都可能需要新增。这些函数的开发不同于一般的应用代码——需要理解数据库内部的内存管理、类型系统、错误处理约定，还要处理跨函数的依赖关系。
DBCooker 的方法分三步走：首先是函数表征，聚合 SQL 标准文档、已有实现、测试用例等多源声明，识别出每个函数需要编写的独立单元及其依赖关系。然后是伪代码引导的合成，不是让 LLM 直接生成完整代码，而是先生成一个结构化的实现骨架（标注了哪些部分可以复用已有函数的引用），再用”混合填空”模型将核心逻辑和可复用例程集成。最后是三级渐进验证：语法检查 → 标准合规性检查 → LLM 引导的语义验证。
在 SQLite、PostgreSQL 和 DuckDB 三个数据库上的实验表明，DBCooker 比通用代码生成方法（包括 Claude Code）的准确率平均高出 34.55%，并且成功为 SQLite v3.50 合成了目前尚不存在的新函数。
对数据工作的启示：
这项工作对数据平台团队有直接的参考价值。很多公司在 PostgreSQL/ClickHouse 等数据库上维护大量的 UDF（用户自定义函数），但开发和测试成本高昂。DBCooker 的”表征 → 骨架 → 填空 → 验证”流程可以直接套用到 UDF 开发流程中。关键是第一步的函数表征——把函数规格说明、已有实现的代码模式、测试用例组织成结构化的 context，比直接把需求丢给 LLM 效果好得多。
4. 缺失值下的概率查询语义：用贝叶斯网络建模数据质量
作者：Leopoldo Bertossi, Farouk Toumani, Maxime Buron | 机构：Universidad Adolfo Ibáñez · Université Clermont Auvergne 发表时间：2026-04-07（arXiv 提交） 链接：arXiv · PDF
核心发现：
数据库中的缺失值（NULL）是数据质量的核心问题，但 SQL 标准对 NULL 的三值逻辑处理长期以来饱受批评——它假设缺失是”完全随机”的，不区分”数据没采集到”和”值本身不存在”和”出于隐私被删除了”这几种本质不同的缺失原因。
本文提出了一个根本性的理论革新：用贝叶斯网络（称为”缺失图”）来显式建模缺失值的成因机制。具体来说，缺失图中的节点对应数据库属性，边表示属性之间的依赖关系如何影响缺失概率。比如在医疗数据中，“是否有某项检查结果”往往取决于”初诊结果是否异常”——这种依赖关系在传统 NULL 处理中被完全忽略。
在这个框架下，带缺失值的数据库被建模为一个块独立的概率数据库。论文给出了两种查询回答方法，它们能够捕捉隐式缺失值填补中的概率不确定性，并保证统计合理性。同时给出了计算复杂度的刻画，说明哪些查询类在这种语义下仍然是可行的。
对数据工作的启示：
如果你的数据管道中有大量缺失值处理逻辑（几乎所有数据工程项目都有），这篇论文值得认真消化。核心启发是：不要把缺失值当作单一现象处理。实践中可以做的第一步是在数据字典中标注每个字段的缺失类型（MCAR/MAR/MNAR），第二步是在数据质量报告中加入缺失模式分析——哪些字段的缺失是联动的。即便不做概率查询，仅仅理清缺失机制就能大幅减少下游分析的偏差。
5. 删除 ≠ 遗忘：推断感知的数据库隐私删除
作者：Vishal Chakraborty, Youri Kaminsky, Arnav Abhijit Dhariya, Sharad Mehrotra, Felix Naumann, Sarvesh Pandey | 机构：UC Irvine · HPI (Hasso Plattner Institute) 发表时间：2026-03-31（arXiv 提交）· SIGMOD 2026 SeQureDB Workshop 接收 链接：arXiv · PDF
核心发现：
GDPR 时代的”被遗忘权”给数据库系统提出了一个看似简单实则深刻的问题：用户点了”删除”，数据真的被遗忘了吗？ 这篇论文的回答是：远没有。
论文系统地分析了两个推断泄漏渠道。第一个是删除后状态泄漏：即使某条记录被删除，数据库中残留的其他记录、聚合统计、甚至日志信息，都可能让攻击者推断出被删除的内容。比如你删除了一个员工的薪资记录，但部门平均薪资的变化就暴露了信息。第二个更微妙——删除模式泄漏：删除操作本身的时间、频率、范围构成了一种元数据，可以被利用。
基于此，论文区分了三层删除语义：逻辑删除（标记不可见）、物理删除（存储擦除）、和语义删除（保证不可推断）。只有达到语义删除才能真正满足隐私要求，但这需要考虑数据间的依赖结构、查询历史、以及删除操作的全局一致性——计算代价可能极高。
对数据工作的启示：
这篇论文是数据治理和合规团队的必读材料。大多数公司的”删除”实现停留在逻辑删除甚至只是 API 层面的隐藏，远未达到语义删除的标准。短期可落地的建议：(1) 审计你的删除链路——从应用层到存储层，删除操作实际擦除了什么、保留了什么（缓存、日志、备份、聚合表）；(2) 对包含敏感数据的表，在删除后重新计算并发布聚合统计（而非仅做减法更新），避免差值推断；(3) 在数据血缘系统中追踪”哪些衍生数据依赖于可能被删除的源数据”。