AI原生数据库架构设计将模型推理能力嵌入存储引擎的系统探索一、当SQL查询遇上神经网络——数据库架构的边界在哪里在传统数据库的世界里一条SQL查询的生命周期是确定的Parser解析→Optimizer生成计划→Executor执行→Storage Engine读取数据。每个阶段都是确定性的规则引擎——基于统计信息的代价估算、基于规则的查询重写、基于代价的索引选择。这种确定性架构在OLTP场景下运转良好但在面对数据倾斜、冷热分离、复杂JOIN顺序选择等问题时统计信息的失真往往导致次优的执行计划。我们团队在过去两年中探索了一个根本性的问题如果我们将神经网络模型直接嵌入存储引擎层让它在数据读取时就能进行智能过滤和预判数据库的查询效率能否发生质变这不仅仅是在查询优化器前加个AI的渐进式改良而是对数据库存储层架构的重新思考。核心洞察在于存储引擎在读取每个数据页时实际上是在做判断——这个页是否包含目标数据如果包含它可能在哪个位置传统的方式是依赖索引结构和数据字典而AI原生的思路是让模型在存储层直接参与数据筛选。flowchart TB subgraph 传统架构 A1[SQL Parser] -- A2[Query Optimizer] A2 -- A3[Executor] A3 -- A4[Storage Engine] A4 -- A5[磁盘数据页] end subgraph AI原生架构 B1[SQL Parser] -- B2[AI-Enhanced Optimizer] B2 -- B3[Smart Executor] B3 -- B4[AI-Embedded Storage Engine] B4 -- B5[模型推理缓存] B4 -- B6[磁盘数据页] B5 -.-|推理结果| B3 end A5 -.-|传统IO路径| B6二、推理嵌入存储引擎的三个技术层次嵌入存储引擎的模型推理不是简单地把一个ONNX模型放进去调用它涉及三个层次的技术挑战。层次一数据预过滤——用轻量模型减少无效IO。存储引擎在扫描数据页时大多数页面不包含查询需要的数据。传统的Bloom Filter和Zone Map已经提供了粗粒度的过滤能力但它们只关心值是否存在的布尔问题。轻量级分类模型可以做得更精细基于页内数据的统计特征最小值、最大值、基数、数据分布预测该页与查询条件的匹配概率对低概率页面直接跳过。关键设计考量是推理开销与IO节省的平衡。如果模型推理耗时超过跳过页面节省的IO时间那就是负优化。我们的实践发现对NVMe SSD单次随机读约100微秒模型推理必须控制在10微秒以内。使用量化的TinyML模型参数量1万配合CPU的SIMD指令加速可以实现这个目标。层次二智能预取——用序列模型预测访问模式。存储引擎在执行范围扫描时实际上产生了一个数据页的访问序列。LSTM或注意力模型可以学习这个序列的模式提前将后续可能被访问的页面预加载到内存中。这与CPU的硬件预取器原理类似但面向的是数据库页级的访问模式。预取的关键挑战是避免预取污染——预测错误的页面占据了宝贵的Buffer Pool空间挤出了真正需要的数据。我们的方案是为预取页面设置独立的预取缓存区只在命中Buffer Pool未命中的情况下才使用且优先淘汰预取的数据。层次三执行计划动态改写——运行时模型反馈。最激进的设计是让存储引擎层的模型反馈影响上层的执行计划。例如当存储层模型检测到某个数据页的访问成本远超预期数据异常膨胀、大量碎片向优化器发送反馈信号触发执行计划的运行时重新编译。这种跨层通信需要设计新的协议接口对现有数据库架构的侵入性较大。三、工程实现基于MySQL InnoDB改造的原型验证我们基于MySQL 8.0的InnoDB存储引擎进行了原型改造在存储层嵌入了一个轻量级推理器。推理引擎使用ONNX Runtime的C API集成模型格式为量化后的INT8版本以减少推理开销。主要修改了InnoDB的行读取路径在row_search_mvcc函数的数据页读取后、行可见性判断前插入模型推理调用。模型输入是页内前N行的数据分布特征由存储引擎在后台维护输出是该页包含匹配行的概率。// InnoDB存储引擎中嵌入模型推理的简化示例 // 在 row0sel.cc 的行读取路径中插入推理逻辑 static bool page_matches_query_prediction( const page_t* page, const dtuple_t* search_key, float threshold 0.3f) { // 只在全表扫描或大范围扫描时启用推理预测 if (search_key-n_fields 1) { return true; // 无条件扫描不使用推理 } // 提取页内数据的统计特征由后台线程异步维护 PageStats stats; if (!get_page_stats(page_get_page_no(page), stats)) { return true; // 统计信息不可用时不跳过 } // 构建模型输入特征向量 float features[FEATURE_DIM]; build_feature_vector(stats, search_key, features); // 执行轻量级推理target: 10微秒 float prob; int ret model_inference(features, FEATURE_DIM, prob); if (ret ! 0) { return true; // 推理失败时保守处理不跳过 } return prob threshold; }性能测试结果令人鼓舞在SSBStar Schema Benchmark数据集上当查询的选择率低于5%时AI预过滤能减少30%~50%的数据页读取量端到端查询延迟降低20%~35%。但在高选择率查询30%中推理开销超过了过滤收益需要动态判定是否启用。四、架构边界与未解决的问题模型泛化能力。在SSB数据集上训练的模型迁移到TPC-H数据集后准确率大幅下降。模型与应用场景深度耦合目前不具备通用的跨场景泛化能力。这意味着每个部署场景都需要针对性的训练数据。在线学习的不确定性。最理想的情况是模型在生产环境中持续学习——根据实际查询的执行情况自动调整。但这引入了不可预测性同一条SQL在不同时间的执行计划可能不同导致性能不稳定。对于要求确定性执行的OLTP场景在线学习可能弊大于利。存储引擎复杂度。嵌入推理能力增加了存储引擎的代码复杂度和维护难度。调试一个既包含B树逻辑又有神经网络推理的模块对团队的技术栈要求显著提高。版本演化问题。模型需要随数据分布的变化而更新。当数据量从1TB增长到10TB甚至数据分布发生结构性变化时旧模型可能完全失效。模型的生命周期管理需要纳入数据库的运维体系。五、总结将AI推理嵌入存储引擎代表数据库架构从静态优化向动态智能演进的趋势。短期来看轻量级模型在数据预过滤和预取方面的应用已经展现出实用价值。中期来看跨层模型反馈机制将改变优化器与存储引擎的交互方式。长期来看随着专用AI推理芯片如NPU的普及存储引擎可能演化出一个专用的推理加速层。对于数据库内核团队建议从最轻量的数据页预过滤场景切入验证选择计算资源充裕的OLAP场景逐步积累模型训练和推理部署的工程经验。这条路不会一蹴而就但方向已经清晰未来的存储引擎一定会更聪明。