MySQL 新技术系列第二期

📢 MySQL 新技术系列第二期

各位数据库同行、开发者朋友们，大家好！

欢迎回到「MySQL 新技术」系列。在第一期「告别 MySQL 8.0 时代，全景解读 MySQL 9.x 创新版」中，我们系统梳理了从 9.0 到 9.7 的版本策略与核心新特性，明确了 9.7 LTS 已接替 8.0 成为新一代长期支持版。

这一期，我们将聚焦一个贯穿整个 9.x 系列最令人兴奋的技术方向——向量检索（Vector Search）。从 9.0 引入原生 VECTOR 类型，到 9.7 LTS 向量能力的全面成熟，MySQL 正在从传统关系型数据库向「AI-Ready 数据平台」完成关键一跃。本文将带你全景解读 MySQL 向量检索的技术演进、内核实现、生产实践，并展望未来的发展方向。

一、为什么 MySQL 需要向量检索？

1.1 技术背景：从关键词匹配到语义理解

在大模型与检索增强生成（RAG）技术普及的当下，向量检索已从小众能力跃升为通用需求。关系型数据库作为企业数据架构的核心，长期以来以结构化数据管理、ACID 事务、成熟的 SQL 生态为核心优势，但在非结构化数据（文本、图片、音频）的语义检索场景中存在天然短板。

MySQL 作为全球使用最广泛的关系型数据库，也顺应这一趋势完成了向量检索能力的迭代，将向量检索纳入标准功能体系。

1.2 MySQL 引入向量检索的核心价值

价值维度	说明
架构简化	无需额外部署独立的向量数据库（如 Milvus、Chroma），在现有 MySQL 架构中统一管理结构化数据 + 向量数据，降低运维成本
能力互补	支持「SQL 条件过滤 + 向量相似性检索」的复合查询，例如「查询 2024 年发布的、与‘MySQL 向量检索’语义相似的技术文档」
生态兼容	依托 MySQL 成熟的事务机制、binlog、主从复制和备份策略，保障向量数据的安全性和稳定性

1.3 传统方案的痛点

在 MySQL 原生向量能力出现之前，用户往往面临两难选择：要么将向量数据存储为 TEXT/BLOB 类型，通过关键词匹配（LIKE/全文索引）检索，无法理解语义；要么引入独立的向量数据库，但需要面对两套安全模型、两套可观测性体系，以及难以回避的数据一致性问题。MySQL 原生向量检索的引入，正为解决这一困境而生。

二、MySQL 向量检索技术全景图

2.1 两条路径：原生支持 vs 插件扩展

目前，在 MySQL 生态中获取向量检索能力主要有两条路径：

方案	技术实现	适用版本	特点
原生 VECTOR	MySQL 内核原生支持的 VECTOR 数据类型 + HNSW 索引	8.4 LTS / 9.x 系列	官方标准方案，与 MySQL 生态无缝集成
MyVector 插件	开源插件，通过 UDF 和组件机制扩展向量能力	8.0 / 8.4	填补了 8.0 用户无法升级至 8.4 时的能力缺口，无需更改表结构即可添加向量支持

两条路径并非互斥。对于已经运行在 8.0 且暂时无法升级的用户，MyVector 插件提供了平滑的过渡方案；而对于能够升级到 8.4 LTS 或更高版本的用户，原生 VECTOR 无疑是首选。

2.2 原生 VECTOR 数据类型

MySQL 9.0 首次引入了原生 VECTOR 数据类型，允许开发者直接在 MySQL 中存储和操作向量嵌入。

核心参数与函数

项目	说明
存储格式	每个条目为 4 字节单精度浮点值
默认最大长度	2048
绝对上限	16383
VECTOR_DIM()	返回向量的维度
STRING_TO_VECTOR() / TO_VECTOR()	将字符串格式转换为二进制向量表示
VECTOR_TO_STRING() / FROM_VECTOR()	将二进制向量转换为列表格式字符串
向量比较运算符	支持向量之间的等值比较

基本操作示例

-- 创建包含 VECTOR 列的表
CREATE TABLE products (
    id INT PRIMARY KEY,
    name VARCHAR(255),
    embedding VECTOR(1536) NOT NULL
);

-- 插入向量数据
INSERT INTO products VALUES 
(1, 'MySQL 9.7 LTS 发布公告', STRING_TO_VECTOR('[0.12, -0.34, 0.56, ...]'));

-- 查询向量维度
SELECT VECTOR_DIM(embedding) FROM products;

-- 向量相似性检索
SELECT id, name, 
       VECTOR_DISTANCE(embedding, :search_vector, 'cosine') AS similarity
FROM products
ORDER BY similarity
LIMIT 10;

⚠️ DBA 提醒：第一代 VECTOR 实现存在显著限制——向量列不能作为任何类型的键（主键、外键、索引键），且部分函数兼容性有限。在规划大规模向量检索应用时，需充分考虑这一约束。

2.3 HNSW 向量索引

HNSW（Hierarchical Navigable Small World，分层可导航小世界图）是一种先进的近似最近邻（ANN）搜索算法，能够以 O(log N) 的时间复杂度实现高效的向量相似性检索。MySQL 8.4 LTS 首次将 HNSW 索引纳入标准功能体系，MySQL HeatWave 9.5.0 进一步支持自动创建向量索引。

HNSW 的核心优势在于其多层图结构：底层包含所有数据点，上层则是下层的子集，搜索时从上至下逐层定位，大幅缩小搜索范围。

向量索引创建示例（阿里云 PolarDB MySQL 版）：

CREATE TABLE t1 (
    id INT PRIMARY KEY,
    v1 VECTOR(4) COMMENT 'imci_vector_index=HNSW(metric=COSINE, max_degree=16)'
);

其中 metric 参数指定距离度量方式（余弦距离、欧氏距离等），max_degree 控制图中每个节点的最大连接数，直接影响检索精度与构建速度的平衡。

2.4 向量距离函数

MySQL 提供了多种向量距离计算函数，用于衡量两个向量之间的相似度：

函数	距离类型	适用场景
`VECTOR_DISTANCE(·, ·, 'COSINE')`	余弦距离	文本相似度、语义匹配
`VECTOR_DISTANCE(·, ·, 'EUCLIDEAN')`	欧氏距离	图像特征、坐标点相似
`VECTOR_DISTANCE(·, ·, 'DOT')`	点积距离	经归一化后的向量相似度

实际使用中，余弦距离在文本语义检索场景中最为常用，因为它关注的是向量的方向而非模长。

三、MySQL HeatWave：AI 能力的集大成者

如果说原生 VECTOR 是 MySQL 向量检索的「地基」，那么 HeatWave 则是这座大厦的「顶配版本」。

3.1 自动向量存储（Auto Vector Store）

MySQL HeatWave 具备自动创建向量存储的能力：当加载的文件格式为 txt、html、json、doc 或 ppt 时，HeatWave Lakehouse 会自动解析加载的文件并生成向量嵌入，存入 VECTOR 类型列中，开发者无需手动处理嵌入生成和向量化流程。

3.2 自动向量索引创建（9.5.0）

从 MySQL 9.5.0 开始，HeatWave GenAI 支持对频繁查询的 VECTOR 列自动创建向量索引，使用 HNSW 等高级索引结构，实现加速的相似性搜索查询，在准确性与速度之间取得平衡。索引的创建和维护由系统自动完成，管理员无需手动介入，可以通过相关系统变量调整自动索引创建的参数。

3.3 混合搜索（Hybrid Search）

HeatWave 9.5.0 还引入了混合搜索能力，将语义搜索与关键词搜索的优势相结合。当查询中包含特定的产品名称、SKU 或品牌名等关键词信息时，混合搜索能够有效弥补纯语义搜索的不足，返回更高质量的检索结果。

3.4 HeatWave AutoML 增强

HeatWave AutoML 引入了深度推荐模型（Deep Recommendation models），基于 PyTorch 构建深度学习管道，通过生成用户和物品的嵌入向量，实现个性化推荐。同时，日志异常检测能力也得到了增强，通过从日志中提取语义特征，与现有的统计 TF-IDF 特征相结合，显著提升异常检测的准确性。

3.5 内置 RAG 支持

ML_RAG 例程支持检索增强生成，加载大语言模型并在可用的向量存储上进行语义搜索，结合私有数据与大模型，生成更精准的回答。开发者可使用 HEATWAVE_CHAT 例程，通过单个 SQL 命令实现自然语言搜索，大幅降低 AI 应用的开发门槛。

四、MyVector 插件：开源社区的向量解决方案

4.1 项目背景

MyVector 是由 Alkin Tezuysal 等开发者发起的开源 MySQL 插件项目，旨在为 MySQL 带来原生的向量存储和相似性搜索能力。它的设计思路非常务实：充分利用 MySQL 现有的 InnoDB 存储引擎，以加性方式（additive） 扩展向量能力——当向量检索功能出现问题时，OLTP 业务依然保持健康运行。

💡 技术洞察：MyVector 的核心设计原则是 「InnoDB 稳定性优先，向量能力可叠加」 ，这一理念使其成为生产环境向量检索落地的务实选择。

4.2 核心特性

特性	说明
VECTOR(n) 列	支持定义向量列存储密集嵌入（如 BERT 生成的 384 维向量）
HNSW 索引	在向量列上构建 HNSW 近似最近邻索引，实现 O(log N) 检索
距离函数	提供余弦距离、欧氏距离等多种向量距离计算函数
范围查询支持	支持带过滤条件的向量检索（如 `WHERE user_id = X`）

4.3 与 ProxySQL 的协同

在 Pre-FOSDEM 2026 上，ProxySQL 创始人 René Cannaò 与 MyVector 作者 Alkin Tezuysal 联合展示了一套完整的生产级架构：MyVector 提供向量能力，ProxySQL 提供统一控制平面。

架构要点：

ProxySQL 对流量进行分类，将 OLTP 写流量路由到主 hostgroup，将向量相似性查询路由到加载了 MyVector 插件的专用副本
当向量流量激增、副本延迟上升时，ProxySQL 可自动卸载向量负载，避免影响 OLTP P99 延迟
提供从零开始的渐进式迁移路径：先仅用 ProxySQL 做路由和观测，再逐步添加向量列和 HNSW 索引

该方案还提供了一个完整的 RAG 接入管道 CLI 工具（rag_ingest），支持从 MySQL 后端源增量获取数据、分块和转换文本、通过 OpenAI 兼容 API 批量生成嵌入向量、并将结果存回 MySQL 作为向量。

4.4 实战案例：带范围的向量检索

MyVector 的一个重要特性是支持 Scoped Vector Search，即带业务上下文过滤条件的向量检索。例如，在多租户系统中，确保向量相似性检索仅在当前用户的文档范围内进行，而非全局搜索。这一能力对于 RAG 应用至关重要——在问答系统中，检索必须限定在用户有权限访问的知识范围内。

五、性能与可观测性增强

5.1 JSON 优化器的变革

MySQL 9.0 完全重写了 JSON 优化器，带来了 JSON 查询性能的巨大变化。一位开发者的生产经验显示：在 8.0 中运行良好的 JSON_EXTRACT 查询，升级到 9.0 后从 0.3 秒变成了 2.1 秒——虽然优化器改进让部分查询变得更快，但也有查询性能下降。这一案例提醒我们，在进行版本升级时，必须对 JSON 相关的业务查询进行充分的性能回归测试。

5.2 多值索引与 JSON 数组

MySQL 9.0 引入了对 JSON 数组的多值索引支持，解决了长期以来 JSON 数组字段无法高效检索的问题：

-- 在 8.0 中需要全表扫描
-- 在 9.0 中可以创建多值索引
CREATE TABLE articles (
    id INT PRIMARY KEY,
    metadata JSON,
    INDEX idx_tags ((CAST(metadata->'$.tags' AS CHAR(50) ARRAY)))
);

-- 检索速度：8.0 约 450ms（10万行全表扫描）→ 9.0 约 12ms（索引查找）
SELECT * FROM articles WHERE 'mysql' MEMBER OF (metadata->'$.tags');

5.3 触发器延迟加载（9.1）

MySQL 9.1 优化了触发器的处理机制，将触发器的解析和执行分为两个阶段：第一阶段仅读取触发器元数据并存入全局缓存，第二阶段才在实际执行数据修改操作时进行完整解析。这一优化显著减少了仅执行只读查询时的资源消耗。

六、实战指南：从零搭建 MySQL RAG 应用

6.1 架构方案对比

方案	适用场景	优势	劣势
原生 VECTOR（8.4+ / 9.x）	新项目、追求官方标准	官方支持、与 MySQL 生态无缝集成	VECTOR 列不能作键，有功能限制
MyVector + ProxySQL	存量 8.0 系统、生产级要求	加性架构风险可控、支持多租户范围查询	需要额外部署 ProxySQL
MySQL HeatWave	云上部署、AI 深度集成	自动向量存储/索引、内置 RAG、混合搜索	需在 OCI/AWS 等云平台使用

6.2 选型决策树

开始
  │
  ├─ 是否在云上且可使用 HeatWave？
  │    └─ 是 → HeatWave（全自动 AI 能力）
  │
  ├─ 是否可以升级到 8.4 LTS 或 9.x？
  │    ├─ 是 → 原生 VECTOR + HNSW
  │    └─ 否 → MyVector + ProxySQL
  │
  └─ 是否需要多租户范围检索？
       └─ 是 → MyVector + ProxySQL

6.3 数据一致性考量

向量数据与业务结构化数据的一致性，是架构设计中必须慎重对待的问题。原生 VECTOR 存储于 InnoDB，与业务数据在同一个事务中，天然保证 ACID 一致性。MyVector 作为插件运行在 MySQL 内部，同样受 InnoDB 事务保护。相比之下，独立的向量数据库则面临两套存储系统间的数据同步难题。从一致性角度来看，MySQL 内生的向量方案具有根本性的架构优势。

6.4 性能调优要点

索引参数调优：max_degree 控制 HNSW 图中节点的最大连接数，值越大检索精度越高，但索引构建时间和内存占用也越大，需要根据数据规模权衡
批量嵌入生成：使用 rag_ingest 工具时，可通过配置批量大小来控制嵌入生成 API 的调用频率，平衡吞吐量与 API 成本
向量维度选择：常用的文本嵌入模型（如 text-embedding-3-small）输出 1536 维，注意不超过 MySQL VECTOR 的 16383 上限

七、限制与挑战

在拥抱 MySQL 向量检索能力的同时，也需要清醒认识到当前版本的限制：

限制项	说明	缓解方案
VECTOR 列不能作键	9.0 起 VECTOR 列无法作为主键、外键或索引键，影响分区表设计	使用辅助表存储向量+业务 ID 关联
HNSW 索引精度	近似最近邻搜索本质上是近似算法，无法保证 100% 召回精确的 K 个最近邻	适当增大 `max_degree` 和搜索深度参数
函数兼容性	VECTOR 类型不能与数值、字符串等类型直接比较，JSON、全文搜索等函数受限	在应用层完成类型转换和比较逻辑
社区版 vs 企业版	部分高级向量能力（如 HeatWave 自动索引）仅在云版/企业版中提供	社区版用户可选用 MyVector 插件

⚠️ DBA 特别提醒：在决定将向量检索引入生产系统之前，务必在类生产环境中进行充分的性能测试，特别是包含 VECTOR 列与业务表 JOIN 的复合查询场景。

八、未来展望

8.1 技术演进方向

从 9.0 到 9.7，MySQL 向量检索能力的演进主线清晰可见：

版本 9.0：VECTOR 数据类型首秀，打好基础
版本 8.4 LTS：HNSW 向量索引纳入标准功能
版本 9.5：HeatWave 自动向量索引创建、混合搜索
版本 9.7 LTS：向量能力的全面成熟与稳定

8.2 未来可期待的特性

展望 10.x 创新版，社区期待看到以下方向的突破：

VECTOR 列支持作为索引键：当前最大的功能限制
更多向量索引类型：如 IVF、Product Quantization 等
向量压缩与量化：降低大规模向量数据的存储成本
更紧密的 AI 模型集成：在数据库内直接运行轻量级嵌入模型

8.3 行业趋势

MySQL 向量检索的演进，反映了关系型数据库在 AI 时代的重要转型方向。Uber 已将数千个集群迁移至 MySQL Group Replication，故障转移时间从分钟级降至秒级，MySQL 在高可用领域的突破同样令人瞩目。AI 能力与高可用能力的双重进化，正在重新定义 MySQL 作为企业级数据平台的价值边界。

九、总结

本期我们全景解读了 MySQL 9.x 系列在向量检索领域的技术演进：

原生 VECTOR 数据类型与 HNSW 向量索引，使 MySQL 能够原生支撑 RAG、语义搜索等 AI 应用场景
MySQL HeatWave 提供了自动向量存储、自动索引创建、混合搜索和内置 RAG 等高级 AI 能力
MyVector 插件为 8.0 用户和开源社区提供了务实的选择，与 ProxySQL 协同可实现生产级的向量检索架构
原生方案 vs 插件方案 vs HeatWave 三条路径各有适用场景，关键在于根据业务需求和部署环境做出合理选择
当前版本仍存在 VECTOR 列不能作键、函数兼容性等限制，需在架构设计中妥善应对

MySQL 向量检索的成熟，意味着企业可以在不引入额外数据库组件的情况下，在现有 MySQL 架构中构建 RAG 应用、语义搜索和推荐系统——这既是架构简化的胜利，也是 MySQL 向「AI-Ready 数据平台」转型的重要里程碑。

下一期预告：MySQL 新技术系列第三期——「MySQL 9.x 多语言引擎深度解析：JavaScript 存储程序从入门到生产」。我们将深入探讨 MLE 组件的工作原理、JavaScript 存储程序的实战应用场景、与 SQL/PSM 的对比分析，以及在 Percona Server 等开源发行版中的最新进展。敬请期待！

欢迎大家在评论区留言交流，告诉我你最想深入了解的主题，我会在后续系列中优先安排！

📚 参考资料

MySQL 9.0 Reference Manual – VECTOR Data Type
MySQL 8.4 LTS Release Notes – HNSW Vector Index
MySQL HeatWave 9.5.0 Release Notes – AutoML & GenAI Enhancements
ProxySQL Blog: Making MySQL AI-Ready
Bytebase: What’s New in MySQL 9
Oracle Blog: Improve Primary Selection on Failover
Oracle Blog: Accelerate Similarity Search with Automatic HeatWave Vector Index
Tencent Cloud: MySQL 向量检索深度解析
Percona Blog: JavaScript Stored Routines
ITHome: MySQL 9.3 发布
FOSDEM 2025: MyVector Plugin Introduction