火山引擎 RDS MySQL 向量索引：把高性能向量检索带到 MySQL 上

MySQL 原生向量能力的现实需求

随着近两年 AI 的快速发展，像 AI 模型、AI 助手等 AI 产品越来越多，这些 AI 产品几乎都用到了 RAG（检索增强生成）架构。向量数据库也逐渐重要，变成了业务不可缺少的数据库，但对于绝大多数的 MySQL 数据库用户来说，业务数据全部存储在 MySQL 中，如果需要向量检索就需要额外再部署一个向量数据库，不仅会导致数据查询链路变长，增加查询耗时，多部署一个数据库，数据同步的成本和对该数据库的运维成本也会增加。

为了解决 MySQL 用户的这个问题，火山引擎 RDS MySQL 正式推出了高性能向量索引，用户不用再单独部署向量数据库，可以让您在一张 MySQL 表里同时执行常规业务查询和向量检索，仅依赖 MySQL 数据库即可完整实现 RAG 业务能力。

与主流数据库向量能力的差异

Oracle 在 MySQL 9.0 中新增了 VECTOR 向量字段类型和一些转换函数，但是没有支持向量索引。如果用户想要做高性能近似最近邻（ANN）向量检索，要么需要扫描全表的数据，要么就是去额外购买付费的 HeatWave 组件。而火山引擎提供了轻量化、更有优势的检索方案：

• 在 MySQL 8.0 和 MySQL 8.4 版本上都支持高性能向量索引，不需要升级到 MySQL 9.x 版本，也不需要购买额外的付费 HeatWave 组件。
• 完全兼容 MySQL 9.x 的标准 VECTOR 向量字段定义和向量转换语法，不用改造业务代码，维护成本低。

下表列举了各数据库的原生向量能力的功能差异：

各数据库原生向量能力的功能差异

索引构建速度：提升 4~6 倍

MariaDB 的向量索引都是采用串行索引构建的，这就导致了构建大量向量索引的耗时极长。而火山引擎依靠自研的高性能并行构建引擎，打破了向量索引构建的瓶颈，即使是百万级向量数据，也可以快速构建向量索引。

本次测试使用参数 m=16、ef_construction=128 的 HNSW 索引配置，选取两组不同向量维度的数据集，统计了从向量数据载入至索引构建的整体耗时。

索引构建耗时对比

根据柱状图的对比数据，可以得出以下结论：

• 1536 维、5 万条向量数据：MariaDB 构建索引耗时 126 秒，pgvector 构建索引耗时 27.76 秒，火山引擎 RDS MySQL 构建索引耗时 22 秒。火山引擎 RDS MySQL 构建索引的速度相比 MariaDB 提升约 6 倍。
• 768 维、100 万条向量数据：MariaDB 构建索引耗时 2524.5 秒，pgvector 构建索引耗时 378.5 秒，火山引擎 RDS MySQL 构建索引耗时 645.6 秒。火山引擎 RDS MySQL 构建索引的速度相比 MariaDB 提升约 4 倍。

向量数据集越大，并行构建向量索引的效率提升越明显，在百万级向量索引构建场景下，索引的构建时间从 42 分钟缩短到至 11 分钟以内。

索引存储大小：减少 2~4 倍

原生 pgvector 仅支持 Float32 向量存储，构建的索引占用的磁盘空间较大。而火山引擎 RDS MySQL 提供 SQ16、SQ8 两种标量量化，用更紧凑的方式存储向量索引。

索引大小对比

结合上述柱状图对比数据，可以得出以下结论：

• 1536 维、5 万条向量数据：MariaDB 构建的索引大小为 218.1 MB，pgvector 构建的索引大小为 391 MB，火山引擎 RDS MySQL 构建的索引大小为 220.4 MB。
• 768 维、100 万条向量数据：MariaDB 构建的索引大小为 2.135 GB，pgvector 构建的索引大小为 3.906 GB，火山引擎 RDS MySQL 构建的索引大小为 2.219 GB。

相比 pgvector，开启 SQ16 量化后索引大小可缩减至 1/2，SQ8 量化后进一步缩减至 1/4，可以有效减少向量索引占用的磁盘空间，降低存储成本。

高召回下查询吞吐：领先 pgvector 2~3 倍

本次性能测试使用行业公认基准工具 VectorDBBench 执行，基于高召回率的实用业务区间，统计各数据库向量检索吞吐（QPS）指标。

高召回率下 QPS 对比

结合上述柱状图对比数据，可以得出以下结论：

• 1536 维 5 万条向量数据、97% 召回率：MariaDB 向量检索吞吐（QPS）为 5326，pgvector 向量检索吞吐（QPS）为 3600，火山引擎 RDS MySQL 向量检索吞吐（QPS）为 8334。相比之下，火山引擎 RDS MySQL 的向量吞吐（QPS）约为 MariaDB 的 1.6 倍、pgvector 的 2.3 倍。
• 768 维 100 万条向量数据、95% 召回率：MariaDB 向量检索吞吐（QPS）为 3703，pgvector 向量检索吞吐（QPS）为 2100，火山引擎 RDS MySQL 向量检索吞吐（QPS）为 4838。相比之下，火山引擎 RDS MySQL 的向量吞吐（QPS）约为 MariaDB 的 1.3 倍、pgvector 的 2.3 倍。

RDS MySQL 即 RAG 向量库

除了具备高性能向量索引的能力外，是否能低成本、快速便捷地接入 AI 应用也很重要。火山引擎 RDS MySQL 官方适配 LangChain、LlamaIndex 两大主流 RAG 开发框架，将底层的向量操作 SQL 封装成标准的 vector_store 接口，仅调用框架标准 API 即可完成向量表和向量索引的创建、向量的增删改查、相似度检索等操作。开发者不用再手写 SQL，即可将 RDS MySQL 作为 RAG 框架原生向量存储后端。

综上所述，您的 MySQL 实例可以直接作为向量数据库去使用，无需再额外部署 Milvus、Pinecone 或 Weaviate 等向量引擎数据库了；并且业务数据和向量数据存储在同一张表中，也保证了业务数据与向量数据的一致性。

from langchain_community.vectorstores import MySQLVectorStore

vectorstore = MySQLVectorStore(
    connection_string="mysql+pymysql://user:pass@rds-endpoint:3306/mydb",
    embedding_function=embeddings,
    table_name="documents"
)

# 直接当向量数据库用
results = vectorstore.similarity_search("如何配置数据库备份？", k=5)

JOTO 企业落地观察

• 企业若已深度依赖 MySQL 作为核心业务数据库，引入该能力可避免新增向量数据库带来的数据一致性治理负担，尤其适用于对事务强一致性和跨表关联查询有刚性要求的金融、政务类 RAG 场景。
• 向量索引与业务表共存的设计，降低了 RAG 系统的部署复杂度，但要求团队具备 MySQL 内核级向量能力的运维认知——传统 DBA 需补足 ANN 索引调优、量化参数选型等新知识域。
• LangChain/LlamaIndex 的开箱适配大幅压缩了原型验证周期，但企业需评估其封装层对高级向量操作（如混合过滤+向量检索、动态权重融合）的支持边界，避免后期因框架抽象泄漏导致二次开发成本上升。
• 标量量化（SQ16/SQ8）虽节省存储，但会引入精度损失；企业在选择量化策略时，需在召回率稳定性与磁盘成本间做显性权衡，不能仅依据“缩减至 1/4”这一数值做决策。