获课：shanxueit.com/12448/

向量 MySQL 结合大模型构建本地知识库：我的选型与落地思考

聊起给大模型搭一个“本地大脑”，最近常被问到的一个问题是：向量数据库那么多，为什么非要用 MySQL？说实话，这问题我纠结了很久。我先后试过独立的向量库（比如 Milvus），也试过轻量的 Chroma，最后把目光落在了带向量能力的 MySQL 身上。这篇文章不讲代码，只聊我个人的决策逻辑和落地感受。

不是炫技，是被现实逼的

最开始做本地知识库项目时，我的第一反应也是“专业的事交给专业的工具”——独立向量库性能好、算法成熟，听起来很完美。但真正推进的时候，麻烦就来了。

最大的痛点是数据一致性。业务数据在 MySQL 里，向量在另一套系统里。用户更新了一条产品描述，业务表改了，向量得重新生成再写到向量库。两套系统之间没有事务，中间那几秒甚至几分钟的窗口里，用户搜到的可能还是旧内容。我遇到过一个案例，电商团队因为这个吃了大亏，搜到的价格和实际对不上，投诉电话被打爆。

第二个痛点是运维成本。对一个中小团队来说，多维护一套向量库集群，就意味着多一套监控、一套备份、一套故障排查流程。出问题的时候翻两边的日志，定位时间直接翻倍。我的团队就几个人，实在不想把精力耗在这上面。

为什么转向带向量的 MySQL

转折点出现在我发现 MySQL 8.0.31 及以上版本已经原生支持 VECTOR 数据类型和向量索引。那一刻的想法是：既然关系库自己能做向量检索了，为什么还要硬拆成两套系统？

核心优势我总结为三点：

第一，事务一致性有了保障。 业务字段和向量 embedding 放在同一张表里，更新操作在一个事务中完成，不存在“两边对不上”的问题。这对知识库场景太重要了——文档更新后，用户马上能搜到最新内容，不会有延迟窗口。

第二，一条 SQL 搞定混合检索。 知识库查询很少是纯粹的语义搜索，通常还附带条件过滤，比如“最近三个月发布的、属于合规分类的文档”。在融合方案里，一条 SQL 就能同时完成结构化过滤和向量相似度排序。不需要先在关系库查 ID 列表，再去向量库查 embedding，最后在应用层拼装。这种“单库搞定”的架构大幅降低了系统复杂度。

第三，运维负担没有增加。 还是原来那套 MySQL，备份恢复走同一条路，监控还是那些指标。团队不用重新学一套新系统，DBA 也不用额外维护一套集群。对于没有专职运维的小团队来说，这一点甚至比性能更重要。

也要接受它的局限

话说回来，不是所有场景都适合用 MySQL 做向量。如果你的业务要处理亿级高维向量、每天跑超高并发查询，那独立向量库仍然更合适。我的判断标准是：数据量在百万级以内、查询 QPS 不算夸张、团队没有专职 DBA——这时候融合方案的性价比最高。

还有一个容易被忽略的点是数据安全。对于金融、政务这些对数据出域有严格要求的行业，本地化部署是底线。带向量的 MySQL 可以完全跑在内网，数据不离开企业边界，这个优势在合规层面很关键。

一点个人体会

回头来看，选择向量 MySQL 这条路，本质上是在“专业极致”和“综合省心”之间做了一个取舍。它可能不是性能天花板，但对于大部分需要落地本地知识库的中小团队来说，它提供了一个足够好用、且不需要额外操心运维的务实方案。

大模型落地的瓶颈往往不在模型本身，而在于知识库的“鲜活度”和“可检索性”。当你的向量检索和业务数据能在一个库里协同工作时，至少你在数据一致性这条路上，少了一个让人失眠的隐患。