MySQL 拥抱 AI：向量、RAG、AutoML 全进了数据库

[01 过去想让数据库「会回答」，得先搭一整套东西](#01 过去想让数据库「会回答」，得先搭一整套东西)
[02 MySQL 把「存、找、答、预测」四件事收进了数据库](#02 MySQL 把「存、找、答、预测」四件事收进了数据库)
[03 实操：给我的「座位派」做一个会回答的帮助中心](#03 实操：给我的「座位派」做一个会回答的帮助中心)
[04 本地跑还是上云：按你的场景选](#04 本地跑还是上云：按你的场景选)
[05 动手之前，这五个坑要先知道](#05 动手之前，这五个坑要先知道)
[06 我的判断：什么项目值得上这套能力](#06 我的判断：什么项目值得上这套能力)
- 参考资料

这篇文章写给想给工具或产品加「AI 问答」能力、又不想单独搭一套向量数据库 + 嵌入服务的开发者------尤其是独立开发者和中小团队。读完你会得到三件事：MySQL 把「存、找、答、预测」做进了数据库的哪一步、怎么用一条 SQL 给工具做问答、以及什么情况下才值得上。

看似普通的工作流，正在被新的工具重新组织。

做独立开发这段时间，我最大的体会是：做工具不难，难的是用户一天到晚问你同样的问题。

「名单怎么导进去？」「座位能按身高排吗？」「我买的会员在哪个工具里用？」------这些问题写进文档没人看，挂在群里天天重复。

我一度想给工具做个「会回答问题的帮助中心」：用户直接打字提问，系统从文档里找到答案。但查了一圈资料，第一反应是劝退------要单独搭向量数据库，要接嵌入模型，要把业务数据复制一份出去，还要维护两套存储。

直到我仔细看了 MySQL 最近几个版本的变化，才发现这条路已经被它自己走完了。

这篇不讲空话，就讲清楚三件事：MySQL 到底把「存、找、答、预测」这四件事做进了数据库里的哪一步、我怎么用它给我的工具做问答、以及什么情况下值得上。

01 过去想让数据库「会回答」，得先搭一整套东西

先说清楚「让数据库会回答问题」这件事，以前有多麻烦。

你手头有一堆资料：产品说明书、客服话术、使用文档。你想让用户直接提问，系统能答上来。标准做法是 RAG（检索增强生成）：先把文档切段、转成向量，存进专门的向量数据库；用户提问时，把问题也转成向量，去向量库里找出最相关的几段；最后把这些段落丢给大模型，让它组织答案。

麻烦在中间两步：向量数据放哪？嵌入和生成用谁？

传统方案是引入 Pinecone、pgvector 这类专门组件，或者自己写服务调大模型 API。数据要导出、转换、同步，多了一套系统要维护。对小团队和独立开发者来说，成本不低。

MySQL 的做法是：这些环节全部收编进数据库，SQL 还是那个 SQL。

02 MySQL 把「存、找、答、预测」四件事收进了数据库

从「存」到「预测」，MySQL 正在把 AI 的四件事收进数据库。

下面按一个开发者真正关心的链路来看，MySQL 分别在哪个环节加了东西。

存：表里多了一种向量列。

2024 年 7 月发布的 MySQL 9.0，表结构里多了一种 VECTOR 列类型。你可以把一段话、一篇文章编码成一串小数存进去------语义上越接近的内容，这串数就越像。社区版就能建这种列，写入用 STRING_TO_VECTOR()，读出来用 VECTOR_TO_STRING()。默认长度 2048 维，最多 16383 维，每一维是 4 字节的单精度浮点数。

需要留意：目前这种列不能当主键，也不能建普通索引。

找：距离函数直接算相似度。

有了向量，检索就有了抓手。DISTANCE() 能算两个向量之间的距离，支持余弦距离、点积、欧氏距离三种方式。想找「和这句话意思最像的内容」，一条 SQL 就够了。

答：库内大模型 + RAG 生成带出处的回答。

再往上，MySQL 的 ML_RAG 例程把整个流程串了起来：PDF、HTML、TXT、PPT、DOCX 这类文档可以切段、编码、存进向量表；提问时自动检索相关段落，交给库内的大模型组织答案，返回结果里还带着引用来源，方便核对原句。

预测：AutoML 让「会不会」「值多少」也能用 SQL 算。

如果需求不是问答，而是判断------比如预测一个客户还会不会复购、一个订单会不会逾期------AutoML 例程 ML_TRAIN 可以直接对业务表训练模型，训练和预测都在数据库里完成。

一句话：以前要单独搭一套的「向量 + 检索 + 生成」，现在从同一条 SQL 会话里就能发起。

03 实操：给我的「座位派」做一个会回答的帮助中心

空谈没用，我直接拿自己做的排座位工具（座位派）试了一遍。目标是让用户能问「名单怎么导入」这类问题，系统从帮助文档里找答案。

第一步：建一张带向量的帮助文档表。

为了演示看得懂，向量只用 3 维；真实场景里嵌入模型生成的向量通常是几百维。

sql 复制代码

CREATE TABLE help_docs (
  id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  title VARCHAR(200) NOT NULL,
  content TEXT NOT NULL,
  embedding VECTOR(3) NOT NULL
);

INSERT INTO help_docs (title, content, embedding) VALUES
('名单导入', '名单支持 CSV 格式，表头按姓名、班级、学号排列后上传即可。', STRING_TO_VECTOR('[0.92, 0.11, 0.04]')),
('排座规则', '可以按身高、视力或指定名单自动排座，规则在设置里勾选。', STRING_TO_VECTOR('[0.08, 0.88, 0.12]')),
('会员权益', '会员可导出座位表为图片，普通用户只能在线查看。', STRING_TO_VECTOR('[0.14, 0.09, 0.91]'));

SELECT id, title, VECTOR_TO_STRING(embedding) FROM help_docs;

第二步：用语义检索找出「最接近的问题」。

用户问「名单怎么弄进来」，先把它编码成向量，再和表里的向量比距离：

sql 复制代码

SET @q = STRING_TO_VECTOR('[0.90, 0.13, 0.05]');

SELECT id, title, content,
       DISTANCE(embedding, @q, 'COSINE') AS distance
FROM help_docs
ORDER BY distance
LIMIT 2;

距离越小越接近，这里排在前面的是「名单导入」。第三个参数换成 'DOT' 或 'EUCLIDEAN'，就是另外两种距离算法。

第三步：让数据库按你的文档生成回答。

单句文本可以用 ML_EMBED_ROW 编码；整张表的文本用 ML_EMBED_TABLE。文档文件（比如 PDF）则先装进向量存储------本地用 file:// 指向本机目录，云上用对象存储。问答时指定向量表和模型选项：

sql 复制代码

SET @query = 'How do I import the roster?';
SET @options = JSON_OBJECT(
  'vector_store', JSON_ARRAY('seat_helper.help_vectors'),
  'model_options', JSON_OBJECT('language', 'en')
);
CALL sys.ML_RAG(@query, @output, @options);
SELECT JSON_PRETTY(@output);

返回的 JSON 里，text 是组织好的回答，citations 是参考过的段落和距离。

如果还想做「预测」------比如根据历史数据判断一个班级会不会有人重复选座------AutoML 例程长这样：

sql 复制代码

CALL sys.ML_TRAIN(
  'seat_helper.t_seat_log',
  'will_conflict',
  JSON_OBJECT('task', 'classification'),
  @model
);

问答解决「从文档里找答案」，预测解决「从数据里学规律」，两件事都用 SQL 发起，但解决的问题完全不同。

04 本地跑还是上云：按你的场景选

MySQL 的 AI 能力有两个落点，选哪个取决于你的场景：

维度	本地：MySQL AI	云上：HeatWave GenAI
形态	MySQL 企业版的本地部署选项	MySQL HeatWave 云服务内置
数据	全部留在自己机房	在云上
模型	库内大模型，CPU 就能跑，不用 GPU	库内/外部 LLM，多语言支持更广
适合	数据敏感、要求数据不出内网	已在用云、要更强性能和更多功能
门槛	企业版许可 + 32 逻辑 CPU / 128GB 内存 / 512GB 磁盘	云资源按需

关键一点：两边的例程是同一套，本地写好应用，以后可以不改代码迁到云上。

如果只是想先看看向量列长什么样，社区版 MySQL 9 就够；距离计算、库内嵌入、ML_RAG 这些，才需要 MySQL AI 或 HeatWave。

05 动手之前，这五个坑要先知道

坑 1：Windows 跑不了 MySQL AI。 官方只支持 Oracle Linux 8 和 Red Hat Enterprise Linux 8，还要求企业版许可和上面那套不小的机器配置。个人开发机想体验，只能先拿社区版玩 VECTOR 列。

坑 2：中文问答效果要实测。 MySQL AI 的 language 参数官方支持列表是 en/fr/de/hi/it/pt/es/th 八种，里面没有中文。好消息是默认嵌入模型 multilingual-e5-small 是多语言的，中文文档可以正常摄入、正常向量检索；但库内模型组织答案时，中文效果怎么样，要以你当前版本文档实测为准。

坑 3：向量列不能建索引。 数据量上来之后，靠全表扫描找相似向量性能会吃紧，召回方式和维度要按官方文档重新设计。示例只是用来走通流程。

坑 4：演示用的 3 维向量不是真实场景。 手写数字只是让人看懂原理。真实嵌入由模型生成，通常几百维，而且提问和文档必须用同一个模型编码，否则检索结果没有意义。

坑 5：上生产前要按数据量重做。 官方示例能跑通，不代表生产可用。向量存储、维度选择、距离算法、模型选择，都要按你的数据规模重新设计、压测。

06 我的判断：什么项目值得上这套能力

折腾完一圈，我给自己定了个判断标准，分享出来：

第一，先问有没有「文档要被反复问」的场景。 客服、使用说明、制度条款这类，值得上；没有这种场景，先别急着引入。

第二，再问数据能不能出库。 敏感数据选本地 MySQL AI，能上云选 HeatWave，两边例程一致，可以先本地写、后迁云。

第三，问团队有没有条件。 Linux 服务器、企业版预算、足够的机器配置，缺一个就先在社区版上把 VECTOR 列玩熟，等条件齐了再升级。

MySQL 还是那个存订单、跑事务的数据库，这一点没变。变的是：按意思找资料、生成一段带出处的回答，现在也可以从同一条 SQL 会话里开始了------对一个想把工具做得更聪明的独立开发者来说，这省掉的是一整套系统。

我是蜗牛，一名正在用 MySQL 造工具的独立开发者。这篇如果对你有用，欢迎关注，咱们一起把技术踩坑路走通。

参考资料

MySQL 官方文档 MySQL AI（dev.mysql.com/doc/mysql-ai/）：向量存储、ML_RAG、ML_TRAIN、AutoML、language 参数支持列表（en/fr/de/hi/it/pt/es/th，无中文）、嵌入模型 all_minilm_l12_v2 与 multilingual-e5-small（默认）、库内 LLM llama3.2-3b-instruct-v1
MySQL AI 官方平台要求页（dev.mysql.com/doc/mysql-ai/26.7/en/mysql-ai-platforms.html）：仅支持 Oracle Linux 8、Red Hat Enterprise Linux 8；32 逻辑 CPU / 128GB 内存 / 512GB 磁盘；需企业版许可
MySQL 9.0 Release Notes / 9.0 参考手册：VECTOR 类型引入（2024-07-01），默认长度 2048，上限 16383 维，每维 4 字节单精度浮点；不能当主键或普通索引；STRING_TO_VECTOR / VECTOR_TO_STRING
MySQL AI Release Notes（dev.mysql.com/doc/relnotes/mysql-ai/en/）：MySQL AI 为企业版 add-on，随 9.7 LTS（2026-04-21）与 26.7（2026-07-28）等版本发布
HeatWave User Guide：ML_RAG、ML_GENERATE、Vector Store 摄取格式（PDF/PPT/TXT/HTML/DOC）、混合检索（9.5.0 起）、9.2.1 起按嵌入模型匹配向量表

事实核验时间：2026-10-17。文中示例仅用于演示原理，生产使用请以官方文档为准。文中头图、链路图、封面图均为 AI 生成示意图。