重要前置说明原生VECTOR列类型是MySQL 9.0 社区版 即可使用的而库内 LLM 推理、ML_RAG检索生成、ML_TRAINAutoML 等完整 AI 流水线属于MySQL HeatWave GenAI / 企业本地 MySQL AI 的能力。下文分层讲解你可以按自己的环境对号入座。一、MySQL 9.0 AI 能力全景在深入原理之前我们需要先建立一个全局认知MySQL 9.x 的 AI 能力不是某一个孤立功能的加入而是一整套从存储层到计算层再到编排层的系统性扩展。理解这个分层架构是后续所有实践的基础。存储层L1 是最基础的一层也是社区版就能用的部分。核心变化是引入了VECTOR(N)原生列类型允许你在 InnoDB 表中直接存储高维浮点向量。这些向量以 Float32 数组的二进制形式序列化小向量≤768 bytes直接存在 B-Tree 叶子页中大向量则溢出到 overflow page存储策略类似BLOB。这一层的设计非常克制——向量列不能做主键、不能做外键、不能建唯一索引、不能参与分区键。这些限制不是实现上的偷懒而是高维向量在语义上就不适合精确匹配和范围扫描强行套用 B-Tree 只会得到错误的查询结果。计算层L2 在存储层之上提供了向量距离运算能力。MySQL 9.x 新增了向量距离运算符以及STRING_TO_VECTOR、VECTOR_TO_STRING、VECTOR_DIM等内置函数。支持三种距离度量余弦距离适合文本语义检索、L2 欧氏距离适合图像特征匹配、内积适合已归一化向量。这些运算目前是逐行扫描执行的对于百万级以上的向量检索需要依赖 HeatWave 的 scale-out 近似最近邻ANN引擎来加速。编排层L3 是 HeatWave GenAI 带来的质变。它将 embedding 编码、向量检索、Prompt 组装、LLM 推理串联成一个完整的sys.ML_RAG调用。你只需要传入一个自然语言问题系统自动完成问题向量化 → 向量检索 Top-K → 上下文拼接 → LLM 生成 → 引用溯源的全链路。这一层的核心价值在于数据不需要离开数据库SQL 就是 AI 应用的统一入口。智能层L4 进一步提供了 AutoML 能力。通过sys.ML_TRAIN存储过程MySQL 可以在库内自动完成特征选择、算法搜索XGBoost / RandomForest / Logistic Regression 等、超参调优和交叉验证。训练好的模型通过sys.ML_PREDICT_TABLE进行批量推理预测结果直接写回数据库表。整个 ML 生命周期不需要 ETL 到 Python 或 Spark数据不出库合规性和安全性都有保障。下面是这四层架构的全局视图二、底层原理深度拆解理解了架构分层之后我们深入每一层的技术细节搞清楚为什么这样设计以及实际运行中发生了什么。2.1 向量列的物理存储原理当你执行CREATE TABLE t (emb VECTOR(384))时MySQL 在 InnoDB 中做的事情远比看起来复杂。首先384 维 Float32 向量占用 384 × 4 1536 bytes这已经超过了 InnoDB 页内单行数据的推荐阈值。因此InnoDB 采用了与BLOB类似的存储策略向量数据的前 768 bytes 存在 B-Tree 叶子页中超出部分存储在独立的 overflow page 链上。向量前面还有一个 header prefix记录维度元信息用于运行时快速校验。这个设计带来了一个重要推论向量列的读取涉及随机 I/Ooverflow page 可能不在内存中因此在高并发场景下向量列的访问延迟会高于普通数值列。如果你的应用需要频繁扫描大量向量应该考虑将向量表与业务表分离或者利用 HeatWave 的内存列存引擎来加速。为什么向量列不能做索引键根本原因在于高维向量的维度灾难。在 384 维空间中几乎所有向量对之间的距离都趋于相等距离集中现象B-Tree 依赖的有序性在高维空间中完全失效。即使你强行对向量做 B-Tree 索引查询优化器也无法利用它进行有效的范围剪枝。因此 MySQL 直接禁止了这种用法引导你使用专门的向量索引如 HNSW、IVF或 HeatWave 的 ANN 引擎。2.2 向量相似度计算引擎向量相似度计算是 RAG 和语义检索的核心。MySQL 9.x 支持三种距离度量每种都有其数学特性和适用场景。余弦距离 的计算方式是1 - (A·B / |A|·|B|)它衡量的是两个向量方向的一致性对向量的长度模不敏感。这意味着无论文本长短只要语义相近embedding 向量的方向就会接近余弦距离就会很小。这是文本语义检索的首选度量。L2 欧氏距离 计算的是√Σ(Ai - Bi)²它同时受向量方向和模长的影响。在图像特征匹配中特征向量通常已经过归一化处理此时 L2 距离与余弦距离等价。但在未归一化的场景下L2 距离可能会因为向量模长的差异而产生误导性的结果。内积A·B在向量已归一化时与余弦相似度等价计算开销最小。如果你的 embedding 模型输出的是归一化向量如multilingual-e5-small使用内积可以获得最佳性能。距离计算目前是逐行执行的优化器不会自动将向量距离计算下推到存储引擎层。这意味着即使你只需要 Top-10 最近邻MySQL 也会扫描全表计算每一行的距离然后排序。对于生产环境的大规模向量检索必须使用 HeatWave 的 ANN 引擎它通过分层可导航小世界HNSW图结构实现了近似最近邻搜索将检索复杂度从 O(N) 降低到 O(log N)。2.3 RAG 检索生成的完整流水线RAGRetrieval-Augmented Generation检索增强生成是 MySQL HeatWave GenAI 最核心的能力。它的设计目标是让 LLM 的回答基于你自己的业务数据而不是依赖模型的训练记忆从而解决幻觉问题并提供可溯源的引用。整个流水线分为四个阶段第一阶段查询向量化。 用户的自然语言问题被发送到 embedding 服务使用multilingual-e5-small模型编码为 384 维向量。这个模型支持 100 语言对中文语义的理解质量在同类小模型中表现优秀且推理速度快适合实时查询。第二阶段向量检索。 查询向量与向量库中的文档片段进行余弦距离计算返回距离最小的 Top-K 个片段。这里的 Top-K 不是固定值而是根据上下文窗口大小和片段长度动态调整的确保拼接后的 Prompt 不超过 LLM 的上下文限制。第三阶段Prompt 组装与生成。 系统将检索到的文本片段作为上下文与用户问题一起组装成 Prompt发送给 LLM Runtime。系统 Prompt 中包含了明确的指令要求 LLM 仅基于提供的上下文回答问题如果上下文不足以回答则如实告知用户。第四阶段引用溯源。 LLM 生成的答案会附带citations数组每个引用包含原文片段、来源文档、页码和距离分数。这是生产环境的关键特性——它让每一句 AI 生成的回答都可以被审计和验证。2.4 AutoML 的库内执行模型传统 ML 工作流需要数据工程师将数据库中的数据导出到 Python 环境进行特征工程、模型训练、超参调优然后将模型部署为 API 服务最后应用通过 API 调用模型。这个流程涉及多个系统、多次数据搬运开发周期长运维复杂。MySQL HeatWave 的 AutoML 将整个流程压缩到 SQL 调用中。当你执行CALL sys.ML_TRAIN(db.table, target_column, ...)时系统自动完成以下子步骤特征选择自动识别表中的数值列、类别列、文本列对类别列进行编码对文本列进行 TF-IDF 或 embedding 转换。算法搜索在 XGBoost、RandomForest、Logistic Regression、SVM 等候选算法中自动选择最适合当前数据和任务的算法。超参调优使用贝叶斯优化策略在超参空间中搜索最优配置比网格搜索效率高得多。交叉验证使用 K-Fold 交叉验证评估模型稳定性选择泛化能力最好的模型版本。训练完成后模型以序列化形式存储在 MySQL 内部表中。推理时通过sys.ML_PREDICT_TABLE对整张表批量打分结果直接写入指定的输出表。整个过程中数据从未离开数据库进程消除了数据泄露风险也避免了网络传输开销。下图展示了 AutoML 从数据准备到推理落库的完整执行链路重点标注了每一步的输入、处理动作和输出各阶段说明阶段核心动作关键设计数据准备通过 SQL 视图完成特征预处理类型自动推断缺失值自动处理无需导出特征选择自动区分数值/类别/文本列并转换文本列支持 TF-IDF 或 embedding 转换算法搜索在 XGBoost、RF、LR、SVM 中择优根据数据规模和任务类型自动剪枝候选集超参调优贝叶斯优化多轮迭代比网格搜索效率高避免组合爆炸交叉验证K-Fold 评估泛化能力防止过拟合选择最稳定的模型版本批量推理加载最优模型对整表打分结果直接写回数据库无需 API 中转可解释性SHAP 值分析特征贡献度每个预测都附带特征贡献度满足合规要求三、实践落地从零到生产的完整路径理论讲完现在进入实操环节。我按照生产环境的真实落地流程分四个阶段逐步推进。Phase 1环境准备与升级如果你当前运行的是 MySQL 5.7 或 8.0需要先升级到 9.x。官方推荐的平滑升级路径是8.0 → 8.4 LTS → 9.x Innovation。8.4 LTS 是一个长期支持版本先升级到 8.4 可以让你的应用在中间版本上充分验证兼容性确认无误后再升级到 9.x。升级前必须做全量备份。使用mysqldump --single-transaction确保备份一致性加上--routines --triggers导出存储过程和触发器。对于大型数据库建议使用物理备份工具如 Percona XtraBackup来缩短备份窗口。安装 MySQL 9.x 后运行mysql_upgrade工具升级系统表。然后验证向量能力执行CREATE TABLE _probe (c1 VECTOR(8));如果不报错说明向量引擎就绪。注意MySQL 8.0 完全不支持VECTOR语法在 8.0 上执行建表语句会报 1064 语法错误这是最常见的升级踩坑点。Phase 2向量存储与基础检索社区版可用向量表的设计需要仔细考虑。首先向量维度必须与你的 embedding 模型输出维度匹配。multilingual-e5-small输出 384 维所以VECTOR(384)是正确的选择。其次向量列通常配合一个文本列存储原始文本方便检索后展示。第三虽然向量列不能建 B-Tree 索引但你可以对文本列建 FULLTEXT 索引作为辅助过滤条件先通过关键词缩小候选集再在候选集上计算向量距离。写入向量数据时你需要先将文本通过 embedding 模型编码为向量然后以STRING_TO_VECTOR([0.021,0.114,...])的形式写入。在生产环境中这个编码步骤通常由应用层完成调用 embedding API然后将向量和文本一起写入 MySQL。查询时使用运算符计算余弦距离按距离升序排列取 Top-K。注意返回的是距离值越小表示越相似。如果需要相似度分数越大越相似可以用1 - (emb query_vec)转换。Phase 3HeatWave RAG 完整落地当你有了 HeatWave GenAI 环境OCI 或 AWSRAG 的落地变得极为简洁。第一步是将业务文档灌入自动化向量库。支持 PDF、TXT、HTML、DOC、PPT 等多种格式文档可以存放在对象存储中。调用sys.VECTOR_STORE_LOAD存储过程指定对象存储 URI、目标 schema 和表名系统自动完成文档解析、文本切片、embedding 编码和向量写入。整个过程无需编写任何解析代码。第二步是查询。调用sys.ML_RAG传入自然语言问题系统自动完成向量化、检索、生成和引用组装。返回的 JSON 结果包含text答案文本和citations引用数组。每个引用包含原文片段、来源文档名、页码和距离分数。这些引用是生产环境可信度的基石——用户可以点击引用查看原文验证 AI 的回答是否准确。如果需要多轮对话可以使用sys.heatwave_chat。它自动维护会话历史后续问题会携带之前的对话上下文实现连贯的追问体验。Phase 4AutoML 预测流水线AutoML 的落地同样简洁。假设你的订单宽表中有一个will_rebuy列标记用户是否复购你想训练一个模型来预测新用户的复购概率。只需调用sys.ML_TRAIN指定表名、目标列和任务类型classification系统自动完成所有训练步骤。训练完成后通过sys.ML_PREDICT_TABLE对等待预测的数据批量打分结果写入指定的输出表。这个流程的精妙之处在于特征工程、模型选择、超参调优全部自动化你不需要成为 ML 专家也能获得高质量的预测模型。同时数据不出库意味着不需要担心数据隐私合规问题也不需要维护额外的 ML 基础设施。四、架构选型决策树面对不同的业务需求和技术约束如何选择正确的部署方案这个决策树覆盖了最常见的场景。如果你的需求仅限于向量存储和相似度检索MySQL 9.x 社区版完全够用不需要任何额外组件纯 CPU 即可运行。如果你需要 RAG 检索生成或 AutoML 能力则需要 HeatWave GenAI 或企业版。此时关键决策点是数据能否上云如果数据可以放在云端OCI 或 AWSHeatWave 云端方案提供弹性扩展能力最多支持 512 个节点如果数据不能出机房金融、政务、医疗等强合规场景则需要部署 MySQL AI 企业版在本地环境中获得完整的 GenAI 能力。无论选择哪种方案SQL 都是统一的编程接口。这意味着你的应用代码不需要因为部署环境的变化而大幅修改只需要调整连接配置和权限设置。五、生产避坑指南在帮助多个团队落地 MySQL AI 能力的过程中我总结了以下最常见的陷阱和对应的正确做法。陷阱一在 MySQL 8.0 上尝试使用 VECTOR 列。 8.0 系列完全不支持向量语法执行建表语句会直接报 1064 语法错误。正确做法是先升级到 9.0。陷阱二对 VECTOR 列建 B-Tree 索引。 MySQL 明确禁止这种用法因为高维向量不适合 B-Tree 有序性。如果需要加速检索应该使用 HeatWave 的 ANN 引擎或者采用关键词预过滤 向量精排的混合策略。陷阱三社区版调用sys.ML_RAG或sys.ML_TRAIN。 这些存储过程只在 HeatWave GenAI / 企业版中提供社区版中不存在。如果你只有社区版可以自己实现 RAG 流水线应用层调用 embedding API 向量检索 LLM APIMySQL 只负责向量存储和距离计算。陷阱四Embedding 模型混用。 查询时使用的 embedding 模型必须与文档入库时使用的模型一致否则向量空间不同距离计算完全没有意义。HeatWave 9.3 默认使用multilingual-e5-small如果你在应用层自行编码务必确保使用相同的模型。陷阱五试图用 MySQL 向量列替代专用向量数据库。 MySQL 的向量能力定位是结构化业务数据 轻量语义增强的混合场景。如果你的核心需求是高 QPS、大规模向量检索如亿级向量、毫秒级响应应该使用 Milvus、Qdrant 等专用向量数据库MySQL 负责结构化数据管理两者通过应用层协同。六、总结MySQL 9.x 的 AI 能力升级代表了一种范式转变。过去构建一个 AI 驱动的应用需要拼接 MySQL 向量数据库 Python ML 框架 LLM API ETL 管道系统复杂、运维沉重、数据在多个系统间流转带来安全和一致性风险。现在MySQL 9.x 将这些能力逐步内化向量存储和检索在数据库内完成RAG 流水线通过 SQL 调用触发AutoML 让预测模型训练变得像写一条 SQL 一样简单。这种数据在哪智能就在哪的设计哲学不仅降低了技术门槛更重要的是消除了数据移动的摩擦。对于大多数企业来说数据已经在 MySQL 中现在智能也可以直接在 MySQL 中运行不需要重新架构整个数据平台。当然MySQL 的 AI 能力不是万能的。它定位为结构化业务数据 轻量 AI 增强的场景对于超大规模向量检索或复杂的多模态 AI 流水线仍然需要专用工具和平台。明智的做法是根据实际需求选择合适的工具组合让 MySQL 做它最擅长的事——可靠地存储和管理你的核心业务数据同时以最低的成本为这些数据赋予语义理解能力。
