【JchatMind智能体 | 第二天】为何选 PostgreSQL + pgvector 而非 MySQL？

前言：

本项目非原创，我也是作为一名初学者跟着一起学习。项目来源于：代码随想录-知识星球。

代码随想录-知识星球https://wx.zsxq.com/group/88511825151142

在知识星球里看到卡哥分享这个项目，感觉还不错，于是想要学习一下这个项目怎么写。项目日记也会同步更新。（本人不分享本项目源码，支持项目付费）

本文由我学习该项目并结合AI整理总结而来，分享出来学习过程中的心得体会，由浅入深，用于日后的回顾，同时也希望能给你带来帮助。

前言：

[一、RAG 智能体项目对数据库的要求](#一、RAG 智能体项目对数据库的要求)

[二、PostgreSQL + pgvector](#二、PostgreSQL + pgvector)

[1. pgvector 扩展](#1. pgvector 扩展)

[2. 降低复杂度](#2. 降低复杂度)

[3. 与Spring AI生态无缝集成](#3. 与Spring AI生态无缝集成)

[三、为何不选择 MySQL？](#三、为何不选择 MySQL？)

[1. 向量支持起步晚](#1. 向量支持起步晚)

[2. 生态成熟度低](#2. 生态成熟度低)

[3. 缺乏自主可控](#3. 缺乏自主可控)

四、总结

总结

【JchatMind智能体 | 第一天】从最原始的大模型调用开始https://blog.csdn.net/h52412224/article/details/158881257

一、RAG 智能体项目对数据库的要求

传统 Web 项目仅要求数据库存储业务数据、提供事务/索引能力、支持报表查询，但 RAG 项目额外增加了高维向量检索这一核心需求，对应的数据流闭环如下：

用户上传文档 → 解析切分为 Chunk 数据
调用嵌入模型（如 BGE-M3）为每个 Chunk 生成高维向量（float[]）
向量与 Chunk 原始内容一同入库存储
用户提问 → 问题生成向量 → 向量相似度检索 → 返回最相关 Chunk 作为大模型上下文

基于此，数据库必须满足 4 个核心能力：

原生支持高维向量类型，无需非常规存储兜底
支持主流相似度计算
支持 ANN 索引，保障 10w+ 数据量级下的检索性能
与 Java / Spring 生态良好集成

二、PostgreSQL + pgvector

PostgreSQL 搭配 pgvector 扩展，是满足上述需求的「最优解」，核心优势体现在「多合一」和「低门槛」。

1. pgvector 扩展

pgvector 是 PostgreSQL 专用的开源向量扩展，完美覆盖 RAG 场景的向量需求：

提供原生 vector 数据类型，直接定义 embedding vector(1024) 即可存储高维向量
支持 3 种主流相似度计算语法，直接嵌入 SQL 中，简洁直观：
- <->：L2 距离
- <=>：内积
- <#>：余弦距离
支持 ANN 索引（如 ivfflat），优化大规模向量检索性能，创建语句示例：

java 复制代码

CREATE INDEX ON chunk_bge_m3
USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 100);

向量检索 SQL 简洁易懂，可直接复用传统数据库操作逻辑：

java 复制代码

SELECT *
FROM chunk_bge_m3
ORDER BY embedding <#> :queryEmbedding
LIMIT 10;

2. 降低复杂度

这是初期项目最看重的优势，PostgreSQL + pgvector 可实现「一套数据库搞定所有」：

存储层面：同时承载传统业务表（用户、会话、知识库、文档）和向量表（Chunk 向量 + 元数据）
运维层面：仅需维护一套 PostgreSQL 集群，无需额外部署独立向量数据库（Milvus、Qdrant 等），减少备份、迁移、监控的工作量
代码层面：复用 Java 生态熟悉的「主库 + MyBatis/JPA + 自定义 TypeHandler」模式，无需学习新的向量数据库 SDK
扩展层面：初期统一存储，后续若遇性能瓶颈，可再将向量数据拆分至专业向量库，具备平滑演进的空间

3. 与Spring AI生态无缝集成

对 JChatMind 这类 Java 项目而言，顺手很重要：

类型映射简单：仅需自定义 TypeHandler，即可实现 PostgreSQL vector 类型与 Java float[] 类型的相互转换
生态适配成熟：MyBatis/JPA 有大量现成的适配案例，Spring AI 官方也提供了 PostgreSQL + pgvector 的样例代码
可直接复用：开源 RAG 项目中大量采用该组合，DDL 语句、索引配置、检索逻辑均可直接参考，降低踩坑成本

三、为何不选择 MySQL？

并非 MySQL 无法实现向量检索，而是在该场景下「性价比不足」，核心问题集中在 3 点：

1. 向量支持起步晚

历史上 MySQL 无原生向量类型，实现向量存储只能采用「多 float 字段」或「BLOB/JSON 序列化」的兜底方案，前者可读性差、维护成本高，后者无法利用索引，检索性能极差
近两年 MySQL 虽推出向量检索相关能力，但仅支持特定高版本（或云厂商定制版本），配置复杂、文档稀缺，尚未形成稳定的生产级方案
对比 pgvector，MySQL 向量功能的相似度计算、ANN 索引优化均不完善，无法满足 10w+ 数据量级的检索需求

2. 生态成熟度低

社区案例一边倒：Spring AI、LangChain、LlamaIndex 等主流 RAG 框架的 Java 集成案例，几乎清一色采用 PostgreSQL + pgvector，相关问题的解决方案、性能调优经验随处可见
MySQL 向量检索的生态极其薄弱，框架适配模块缺失，大部分问题需要团队自行摸索，对初期项目而言风险过高

3. 缺乏自主可控

MySQL 的部分向量能力仅在商业版或特定云厂商托管版本中提供，存在「厂商锁定」风险
部署环境受限、成本不透明，对希望自建、开源、本地部署的团队不友好；而 PostgreSQL + pgvector 全程开源，可完全部署在自有机器上，自主可控性拉满

四、总结

|----------------------|-----------------------|--------------------|
| 选型维度 | PostgreSQL + pgvector | MySQL |
| 原生向量类型支持 | 支持（pgvector 扩展，成熟稳定） | 仅高版本/云定制版支持，不完善 |
| 向量检索性能与索引 | 支持 ANN 索引，10w+ 量级可用 | 索引支持薄弱，大规模数据性能不足 |
| 生态与案例丰富度 | 极高，大量 RAG/LLM 项目默认选择 | 极低，案例与解决方案稀缺 |
| 工程与运维复杂度 | 低（一套数据库搞定所有） | 高（需额外兜底，或绑定多组件） |
| 自主可控性 | 完全开源，无厂商锁定 | 部分能力依赖商业版/云厂商，可控性弱 |
| Java / Spring AI 适配度 | 高，现成案例与适配模块丰富 | 低，需大量自定义开发 |

对于 JChatMind 这类初期智能体 + RAG 项目，PostgreSQL + pgvector 是兼顾「功能满足、生态成熟、运维简单、自主可控」的稳妥选择，既能够快速落地需求，也为后续的性能扩展预留了空间。

总结

RAG 项目的核心额外诉求是高维向量检索，这是选型的关键依据。
PostgreSQL + pgvector 的核心优势是「一站式解决」，降低工程和运维复杂度，且生态成熟。
MySQL 被弃选的核心原因是向量支持起步晚、生态弱，部分方案还存在厂商绑定风险，不适合初期 RAG 项目快速落地。

上述内容也同步在我的飞书，欢迎访问

https://my.feishu.cn/wiki/QLauws6lWif1pnkhB8IcAvkhncc?from=from_copylink

如果我的内容对你有帮助，请点赞，评论，收藏。创作不易，你们的支持就是我坚持下去的动力！