文档(金鹏): 2026-08-20 章节 26 篇文章摘要归档
- 26 篇微信公众号文章原文+摘要归档至 知识/微信公众平台/{公众号}/
- 9 个主题分组：Skill工程/Agent运行时/数据基础设施/交互工具/产品服务/大模型前沿/产业开源/制造业AI/军事社会
- 生成 9 组配图（2560x1440 大图 + 160x90 thumb）至 知识/金鹏/20260820/
- 知识/金鹏.md 2026-08-20 章节改写为结构化索引（主题标签+配图+金句+分层子条目）
- 1 个小红书视频链接以视频笔记条目保留（内容无法文本化）
Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Claude
@@ -0,0 +1,88 @@
|
||||
# 火山引擎 RDS MySQL 向量索引：把高性能向量检索带到 MySQL 上
|
||||
|
||||
> **来源**：微信公众平台（火山引擎数据库）
|
||||
> **作者**：火山引擎数据库
|
||||
> **发布日期**：2026-08-20（原文未标注明确日期，按下载日占位）
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/f5aEV7az3RYQeivyQUJsYQ
|
||||
|
||||
---
|
||||
|
||||
## 一、火山引擎 RDS 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 向量字段定义和向量转换语法，不用改造业务代码，维护成本低。
|
||||
|
||||
下表列举了各数据库的原生向量能力的功能差异：
|
||||
|
||||
|
||||
|
||||
## 三、RDS MySQL 与 MariaDB、pgvector 的向量索引性能对比
|
||||
|
||||
市面上主流数据库的向量索引存在索引构建耗时长、向量检索耗时长和向量索引占用大量磁盘存储空间这几个痛点。火山引擎 RDS MySQL 针对上述痛点，进行了深度的内核优化，同时从索引构建速度、索引的大小、索引查询性能三个方面，横向对比了与 MariaDB 13.1（同属 MySQL 生态）和 pgvector 0.8.2（PostgreSQL 生态中最受欢迎的向量索引扩展）的差异。
|
||||
|
||||
### 1、索引的构建速度：提升 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、索引的大小：减少 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，可以有效减少向量索引占用的磁盘空间，降低存储成本。
|
||||
|
||||
### 3、索引的查询性能：高召回下查询吞吐领先 2~3 倍
|
||||
|
||||
本次性能测试使用行业公认基准工具 VectorDBBench 执行，基于高召回率的实用业务区间，统计各数据库向量检索吞吐（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)
|
||||
```
|
||||
|
||||
## 总结
|
||||
|
||||
火山引擎 RDS MySQL 为标准的 MySQL 补齐了向量数据存储与高性能向量索引能力，填补了 MySQL 生态在 AI 场景的短板。它支持 MySQL 8.0 和 MySQL 8.4 两个版本，完全兼容 MySQL 9.x 的标准 VECTOR 向量字段定义和向量转换语法，不用改造业务代码，同时也具备高性能索引构建与检索能力，并适配 LangChain、LlamaIndex 开发框架。
|
||||
|
||||
如果您正在为 AI 应用选择向量数据库，又想减少额外部署向量数据库的成本，可以选择火山引擎的 RDS MySQL（点击阅读原文获取），即可一站式落地企业 RAG 业务。
|
||||
@@ -0,0 +1,74 @@
|
||||
# 📊 文章摘要：火山引擎 RDS MySQL 向量索引：把高性能向量检索带到 MySQL 上
|
||||
|
||||
> **原文**：[2026-08-20_火山引擎_RDS_MySQL_向量索引_把高性能向量检索带到_MySQL_上](./2026-08-20_火山引擎_RDS_MySQL_向量索引_把高性能向量检索带到_MySQL_上.md)
|
||||
> **原文链接**：https://mp.weixin.qq.com/s/f5aEV7az3RYQeivyQUJsYQ
|
||||
> **来源**：微信公众平台
|
||||
> **作者**：火山引擎数据库
|
||||
> **发布日期**：2026-08-20
|
||||
> **摘要日期**：2026-08-20
|
||||
> **价值评级**：⭐⭐ 中
|
||||
|
||||
---
|
||||
|
||||
## 核心命题
|
||||
|
||||
> **向量进 MySQL** — 业务数据与向量数据同表共存，仅靠 MySQL 一套系统即可完整落地 RAG，免除额外部署向量数据库的链路、同步与运维成本。
|
||||
|
||||
---
|
||||
|
||||
## 文章概要
|
||||
|
||||
火山引擎数据库团队的产品发布文：RDS MySQL 推出高性能向量索引，在 MySQL 8.0/8.4 上支持 HNSW 向量索引且完全兼容 MySQL 9.x 的 VECTOR 语法，用户可在一张表内同时执行常规业务查询与向量检索。文章给出与 MariaDB 13.1、pgvector 0.8.2 的三方基准对比（VectorDBBench）：索引构建速度提升 4~6 倍（并行构建引擎）、SQ16/SQ8 标量量化使索引体积缩减至 1/2~1/4、高召回率下检索 QPS 领先 2~3 倍，并官方适配 LangChain/LlamaIndex 的 vector_store 接口。价值在于选型参考数据；局限是厂商自测基准、对比对象不含专用向量数据库（Milvus 等）。
|
||||
|
||||
---
|
||||
|
||||
## 关键要点
|
||||
|
||||
1. **一张表内业务查询+向量检索** — 免去"MySQL + 独立向量库"双系统的查询链路变长、数据同步与运维成本 `[分类: 共识]`
|
||||
2. **兼容 MySQL 9.x VECTOR 语法且支持 8.0/8.4** — 不改造业务代码、不强制升级版本、无需购买 HeatWave 付费组件 `[分类: 厂商主张]`
|
||||
3. **并行构建引擎：索引构建提速 4~6 倍** — 百万级向量索引构建从 42 分钟缩短到 11 分钟内（对比 MariaDB 串行构建）`[分类: 厂商数据]`
|
||||
4. **SQ16/SQ8 标量量化：索引体积缩至 1/2~1/4** — 相比 pgvector 仅支持 Float32 存储，存储成本显著下降 `[分类: 厂商数据]`
|
||||
5. **高召回下 QPS 领先 2~3 倍** — 97%/95% 召回率实用区间，QPS 约为 pgvector 的 2.3 倍（VectorDBBench 基准）`[分类: 厂商数据]`
|
||||
6. **官方适配 LangChain/LlamaIndex** — vector_store 标准接口封装 SQL，开发者无需手写 SQL 即可接入 RAG 框架 `[分类: 共识]`
|
||||
|
||||
---
|
||||
|
||||
## 批判性分析
|
||||
|
||||
### 假设前提
|
||||
|
||||
(1) 用户的核心痛点是"多部署一套向量数据库"——对已重度使用 MySQL 的团队成立，对云原生团队未必；(2) 厂商自测基准环境公平——未公开测试硬件、数据集与配置细节；(3) RAG 规模停留在百万级向量——更大规模（亿级）场景未验证。
|
||||
|
||||
### 论据与逻辑
|
||||
|
||||
对比数据具体（维度×数据量×耗时×QPS），有行业基准工具背书，内部逻辑完整。但明显回避了与专用向量数据库（Milvus、Pinecone、Weaviate——文中仅作为"可不再部署"的对象提及）的性能对比；pgvector 0.8.2 的量化能力（halfvec 等）也未讨论。768 维百万级场景中构建耗时（645.6s）实际慢于 pgvector（378.5s），标题的"4~6 倍提升"仅相对 MariaDB，存在选择性表述。
|
||||
|
||||
### 边界与局限
|
||||
|
||||
适用于 MySQL 存量业务团队为 RAG 场景做数据库选型参考；不适用于需要亿级向量、多模态索引、分布式检索的重度向量场景。性能数字为厂商口径，采购前应自行复测。blob 图片链接（功能对比表、性能柱状图）在归档中不可见，关键表格数据依赖原文页面。
|
||||
|
||||
---
|
||||
|
||||
## 可引用金句
|
||||
|
||||
> "用户不用再单独部署向量数据库，可以让您在一张 MySQL 表里同时执行常规业务查询和向量检索，仅依赖 MySQL 数据库即可完整实现 RAG 业务能力。"
|
||||
|
||||
> "在百万级向量索引构建场景下，索引的构建时间从 42 分钟缩短到至 11 分钟以内。"
|
||||
|
||||
---
|
||||
|
||||
## 总体评价
|
||||
|
||||
**亮点**：
|
||||
- 三方对比数据具体到维度、数据量、召回率与 QPS，参考价值实
|
||||
- 兼容 9.x 语法 + 支持 8.0/8.4 的组合拳切中存量用户痛点
|
||||
- LangChain/LlamaIndex 适配降低接入门槛
|
||||
|
||||
**不足**：
|
||||
- 厂商自测，无第三方复现；未对比专用向量数据库
|
||||
- "提升 4~6 倍"仅相对最弱的 MariaDB 基线，对 pgvector 的构建速度并无优势（选择性表述）
|
||||
- 关键性能图以 blob 图片承载，文本不可提取
|
||||
|
||||
**适用场景**：MySQL 存量团队的 RAG 架构选型、向量数据库 vs 关系库一体化的技术评估
|
||||
|
||||
**关联建议**：与 G3 组《从 Data Lake 到 State Lake》《Storage Agent Family》（本批归档）对读，理解火山引擎"数据基础设施全面 Agent 化/RAG 化"的布局；专用向量库场景可对照 Milvus 基准报告
|
||||
Reference in New Issue
Block a user