问题

搭建一个 RAG（检索增强生成）系统时，第一反应往往是”我得搞个 Milvus 或 Qdrant”。但如果你已经有 MySQL 存业务数据，能不能直接用 MySQL 存向量，省掉一个中间件？

直到最近，这个问题的答案是”生产环境别这么干”。但现在情况变了。

变化：MySQL 9.2 原生向量搜索生产就绪

2026 年 MySQL 9.2 发布，HNSW 索引直接集成在 InnoDB 引擎内部，支持 SIMD 硬件加速，性能对标专用向量引擎。

MySQL 8.4 就有 VECTOR 类型，但那更像”能用”的阶段——百万级以内勉强跑，上了生产就开始抖。9.2 版本的关键不在于”支持向量”，而在于向量操作和传统 SQL 操作共享同一套事务、MVCC、备份恢复体系。

这意味着什么？意味着你不需要维护两套数据一致性逻辑。业务数据在 MySQL，向量数据也在 MySQL，一次 JOIN 就能做”找出分类=Java 且语义相似的前 10 个文档”——这在”MySQL + 专用向量库”架构里需要两次查询 + 应用层合并。

Spring AI 怎么接

Spring AI 内置了对多种向量存储的抽象，MySQL 也在其中。核心流程：

1
2
3
4
5
6
7
8
9
10
11
// 1. Embedding 存入 MySQL
vectorStore.add(List.of(
    new Document("Spring AI 1.0 正式发布...", Map.of("category", "java"))
));

// 2. 语义搜索 + 元数据过滤（一次 SQL 搞定）
List<Document> results = vectorStore.similaritySearch(
    SearchRequest.query("Spring AI 怎么接入向量数据库")
        .withFilterExpression("category == 'java'")
        .withTopK(5)
);

Spring AI Alibaba 在此基础上还加了 DashScope 的 Embedding 模型集成，中文场景表现更好。

什么时候 MySQL 够用？

条件 说明
向量规模 < 500 万 MySQL 9.2 HNSW 在这里性能不打折
已有 MySQL 基础设施 不想引入新中间件的运维成本
需要向量 + 关系数据联合查询 MySQL 原生 JOIN 比跨系统拼接简单得多
团队只有 Java 栈 不熟悉 Python 向量库生态

对于大多数企业的内部知识库 RAG（几万到几十万文档），MySQL 9.2 完全够用。用 Milvus 反而杀鸡用牛刀。

什么时候该换专用向量库？

场景 为什么 MySQL 不行
亿级向量 InnoDB 不是为这个设计的，扩容靠主从不是分片
毫秒级 P99 延迟要求 MySQL 的设计目标是稳定吞吐，不是极致延迟
GPU 加速检索 MySQL 没有 GPU 索引能力
多模态向量混合检索 图文音视频向量共存，专用库的管理能力更强
高频写入 + 实时可见 HNSW 在高频删除/更新场景下 dead nodes 积累，需要定期 rebuild

简单说：MySQL 吃掉的是”结构化数据 + 向量数据在一起”的中小规模场景。亿级纯向量检索、多模态、极致延迟这些场景还是专用库的地盘。

架构决策树

1
2
3
4
5
6
你的向量规模？
  ├── < 500 万 → 用 MySQL 9.2，别引入新组件
  ├── 500 万 - 5000 万 → 看是否需要 JOIN 业务数据
  │   ├── 需要 → pgvector（比 MySQL 向量能力更成熟）
  │   └── 不需要 → Qdrant（轻量，内存友好）
  └── > 5000 万 → Milvus 或云托管（Pinecone）

意味着什么

  1. “MySQL + Milvus”不再是小规模 RAG 的默认架构。 MySQL 9.2 让很多项目可以砍掉一个中间件。
  2. 架构简化本身就是价值。 少一个组件 = 少一个故障点、少一套监控、少一份运维负担。
  3. 但对学习和理解来说，专用向量库的技术原理仍然值得学。 HNSW、IVF、PQ 这些索引算法不会因为 MySQL 内置了就消失。你知道 MySQL 的 HNSW 在里面干了什么，才能在出问题时调参。

一句话：MySQL 正在吃掉中小规模 RAG 这个场景。如果你的向量量级在百万级、业务数据已经在 MySQL 里，优先考虑 MySQL 一体方案，别急着往架构里塞专用向量库。