MySQL 与 AI 的交汇点:数据库不再只是＂存数据＂

大概从2023 年下半年开始，数据库圈出现了一个有意思的现象：几乎所有主流的关系型数据库，都在密集地往 AI 方向靠。

PostgreSQL 有了 pgvector 扩展，直接在关系型数据库里存向量。MongoDB 推出了 Atlas Vector Search。就连一向"务实"的 Oracle MySQL，也在 2023 年 9 月的 CloudWorld 大会上宣布了一个名为 HeatWave GenAI 的东西——在 MySQL 里内置向量存储、甚至内置大语言模型。

这不再是"数据库和 AI 是两个独立技术栈"的时代了。两件东西从不同的方向出发，正在往同一个路口汇集。

这篇文章想聊的，就是这个交汇到底发生在哪些维度上，以及它对MySQL 用户意味着什么。

一、AI 管数据库：OtterTune 的实验与结局

如果说"用 AI 管数据库"这条路上有一个标志性公司，那就是 OtterTune。

1.1 它做了什么

OtterTune 的故事起点在卡内基梅隆大学（CMU）数据库实验室，由 Andy Pavlo 教授和他的学生们创立。公司的核心技术思路很简单：数据库有几十上百个可调参数（MySQL 的 InnoDB 缓冲池大小、刷盘策略、连接数阈值、查询缓存行为……），传统 DBA 凭经验、查文档、看监控来调，耗时且不一定最优。OtterTune 的做法是用机器学习模型分析数据库的运行指标，自动推荐参数配置，让数据库"自己管自己"。

公司成立于2021 年 5 月，先后从 Intel Capital、Race Capital 等机构拿到了共计约 1450 万美元的融资。到 2023 年的时候，它同时支持 MySQL 和 PostgreSQL，一度被视为 AI for Database 这个方向的标杆。

1.2 然后呢？它关停了

2024 年 6 月，OtterTune 宣布停止运营。它的官网现在只剩一句话："OtterTune was an automated database tuning service out of Carnegie Mellon University. It is dead."

OtterTune 没有公开详细解释关停原因。但从行业角度看，这个结局至少释放了一个信号："数据库自动调参"这个需求是真实的，但它作为一个独立产品去商业化，比想象中难得多。

OtterTune 的创始人 Andy Pavlo 在关停公告中提到了一些外部因素，但没有展开细节。不过从公开信息来看，大趋势是很清楚的：当 AWS、Oracle、阿里云这些云厂商把类似能力作为一个"内置功能"而非"附加产品"来提供时，独立工具的空间就被大幅压缩了。

1.3 Oracle 的做法：把 ML 直接放进 MySQL

Oracle 的策略确实是这样的。MySQL HeatWave 在 2022 年就推出了 AutoML 功能——一个叫做 `ML_TRAIN` 的存储过程，可以直接在 MySQL 里训练机器学习模型。另外还有 `ML_PREDICT` 做推理、`ML_EXPLAIN` 做模型解释。

核心思路是把机器学习"沉"到数据库引擎里，而不是让用户把数据导出来、送到外部的 ML 平台去训练。这样做的好处是省去了数据搬运的环节——对于数据量大的场景，搬运本身就是一笔不小的成本。

Oracle 官方文档称 AutoML 不需要额外付费（包含在 HeatWave 服务内），这加剧了对独立数据库优化工具的挤压。

从OtterTune 的关停到 Oracle 的内置 AutoML，这条线上能看到一个清晰的行业逻辑：AI 管数据库这件事，最终的承载形态大概率是数据库产品的一个内置能力，而不是一个独立的第三方工具。

二、数据库管AI：向量存储的"入侵"

如果说"AI 管数据库"是一个还在摸索的方向，那么反过来的"数据库管 AI"已经实实在在地落地了。

2.1 为什么数据库需要向量？

大语言模型（LLM）的工作原理决定了：模型本身的知识是"冻结"在训练数据里的，没法实时更新。要让 LLM 回答关于特定业务数据的问题——比如"上周华东区的退货率是多少"——就需要在提问时把相关的上下文"喂"给模型。这就是 RAG（检索增强生成）的核心思路。

RAG 的第一步是"检索"——根据用户的问题，从海量数据里找到最相关的几条。而检索的基础是向量相似度计算：把文本转成向量（embedding），再找向量空间中距离最近的几条记录。

这就导致了向量存储的爆发。传统的做法是搞一个专门的向量数据库——Pinecone、Weaviate、Milvus、Qdrant 等等。但这也意味着数据在"业务数据库"和"向量数据库"之间又多了一套同步链路。

2.2 MySQL 的回应：HeatWave GenAI

Oracle 在 2023 年 9 月的 CloudWorld 上给出了 MySQL 的答案：HeatWave GenAI。

它做了三件事：

第一，引入了原生的VECTOR 数据类型。以前 MySQL 里存向量只能用 `BLOB` 或者 `JSON`，性能有限。有了原生 VECTOR 类型，存储和检索都更高效。

第二，内置了向量存储和检索引擎。用户不需要另起一个向量数据库，在MySQL 里存好向量后可以直接做相似度检索。

第三，更激进的是，它直接在数据库里嵌入了大语言模型。Oracle 的说法是"in-database LLMs"，用户可以用自然语言和数据对话，而不需要把数据发给外部 AI 服务（如 OpenAI API）。

到2024 年，HeatWave GenAI 已经可以在 OCI、AWS 和 Azure 三个云上使用。

2.3 pgvector 的对照

PostgreSQL 生态走的是另一条路。pgvector 是由 Andrew Kane 创建的开源扩展，2021 年前后因为 RAG 热潮被大量采用。它的思路是：给 PostgreSQL 加一个向量类型和对应的相似度检索算子（如 `<=>` 余弦距离、`<>` 欧氏距离），不改变 PostgreSQL 本身的内核。

两条路线的差异很明显。pgvector 是"轻量级附着"——不改内核，用扩展机制挂上去，社区驱动，开源免费。HeatWave GenAI 是"深度集成"——Oracle 从引擎层面做了改造，但它是商业产品，只能在 Oracle 的云体系内使用。

对于MySQL 社区版的用户来说，情况有些微妙。MySQL 9.0（2024 年 7 月发布）确实在社区版中引入了 VECTOR 数据类型，但向量相似度检索的关键函数 `DISTANCE()` 目前仅限 HeatWave（OCI）使用，不在社区版或商业授权版中提供。这意味着社区版用户只能存储向量，却没法在数据库内部做相似度查询——这和 pgvector"存向量 + 搜向量"的完整能力之间，还有差距。

三、自然语言查数据：从实验室到生产的距离

3.1 NL2SQL 在热什么

"用自然语言查 SQL 数据库"的想法其实一点也不新。十几年前就有所谓的"自然语言接口"，但那时候的能力非常有限，只能在预设的模板里做简单的翻译。

从2022 年底 ChatGPT 发布之后，这个领域被彻底激活了。学术界的注意力很能说明问题——2024 年的顶级数据库会议 VLDB 上，同时出现了多个 NL2SQL 相关的论文和基准测试框架，包括 NL2SQLBench 和 NL2SQL360。

基本思路是：一个足够强的LLM 接收用户的自然语言问题，结合目标数据库的 Schema 信息（表结构、字段名、关系），生成对应的 SQL 语句。理论上，这可以让不懂 SQL 的产品经理、运营人员也能直接查询数据库。

3.2 理论很性感，落地有沟壑

但这个"理论上的美好"和"生产环境的可靠"之间，有几道坎。

第一，Schema 理解的粒度问题。一个电商数据库可能有几百张表，字段名叫 `status`、`type`、`flag` 的满天飞。LLM 要准确判断用户说的"状态"对应哪个表的哪个字段，仅靠 Schema 字符串是不够的。这需要人工给字段加注释、维护元数据字典——而这些恰恰是多数业务数据库的薄弱环节。

第二，SQL 的正确性不等于业务正确性。LLM 生成的 SQL 语法可能是对的，但逻辑可能完全跑偏。比如用户问"上个月销售额最高的十个城市"，模型可能 LEFT JOIN 了错误的表、或者误用了聚合字段。用户如果是非技术人员，根本看不出来返回结果有问题。

第三，安全和权限。NL2SQL 如果直接暴露给终端用户，相当于给了用户一个"自然语言版的 SQL 控制台"。不做权限管控，一句"把用户表全删了"可能真的会变成一条 `DELETE` 语句。

学术界在NL2SQLBench 上的测试也证实了这些差距——即便最强的模型，在复杂查询（多表 JOIN、嵌套子查询、窗口函数）上的准确率仍然有显著下降空间。

3.3 务实的一面

这些困难不意味着NL2SQL 没有用。它在某些半结构化的场景下是很有价值的：比如 BI 工具里的"智能查询助手"——用户写了大概意思，系统帮补全成标准 SQL；或者运维场景里的"日志查询"——"把最近一小时错误率超过 5% 的服务列出来"。

更务实的做法可能不是"让人人都能查数据库"，而是把 NL2SQL 当成一个有监督的辅助工具，在生成 SQL 后加一层验证和审批。

四、这三条线指向什么？

把AI 管数据库、数据库管 AI、NL2SQL 这三条线合在一起看，有一件事越来越清晰：

数据库正在从一个"被动存储引擎"变成一个有"主动能力"的计算平台。

过去数据库的工作模式是"你存数据、你查数据、你管数据"，所有智能都在人的脑子里。现在趋势是：数据库自己参与到了"理解数据""优化自己""服务 AI 应用"的过程里。

具体到MySQL 生态，这个趋势带来了几个实际影响：

对于个人开发者和小团队：NL2SQL 可能帮他们省掉写模板查询的时间。向量存储如果有了开源的 MySQL 方案（无论来自社区还是 Oracle），在 RAG 应用里用 MySQL 的用户就不用额外维护一套向量数据库。

对于DBA 和技术管理者：数据库参数调优这类重复性工作，未来大概率会变成数据库的内置自动功能。"手调参数"这件事的去技能化趋势，和云数据库的 Serverless 化是一致的。

对于业务团队：最值得关注的是HeatWave GenAI 这类"数据库内嵌 AI"产品。它解决的核心问题不是技术新不新，而是"数据安全"——不用把敏感业务数据发给外部 AI 服务，模型在数据库内部跑，结果直接返回。这在金融、医疗、政务等合规敏感行业有实际需求。

最后想说的是，这些变化没有一个是在推倒重来。MySQL 还是 MySQL——你昨天的 SQL 今天照样能跑。真正的变化发生在数据库的边界上：它在扩展自己能做什么。而这种"扩展"的方式，正在重新定义"数据库"这三个字的含义。