大家好，我是数据库小学妹👋我踩过的坑，你别再踩。
上个月有个同行找我救火。他们团队被大模型热度带着走，做了一套"纯向量数据库架构"的电商搜索系统，把所有数据都塞进了Milvus。上线第三周运营要拉一份"近7天购买过A商品且收藏过B商品的用户"名单做促销，向量数据库做不了这种多条件精确筛选。临时写了个ETL脚本把数据倒回MySQL跑报表，但两边数据已经不同步，跑出来的数跟前台对不上。运营拿着两张差异表来问，技术负责人一句话答不上来。我去帮他们重构架构，花了一周才把关系型数据层补回去。
这个案例我印象很深。不是因为技术难，是犯这种错的人太多。向量数据库这两年火得离谱，很多人连底层怎么工作的都没搞清就往生产上放。今天把这件事掰开聊聊，希望能帮你少走弯路少踩坑。
向量数据库为什么突然爆了
向量数据库不是新物种。Milvus 2019年开源，Pinecone 2021年成立。真正从"小众工具"变成"必谈话题"是ChatGPT之后的事，根本原因是RAG架构普及了。
大模型有知识盲区。训练数据有截止日期，没有企业的私有业务数据，上下文窗口也有限。RAG的思路是外挂知识库，用户提问时先检索相关片段，再把检索结果和问题一起丢给大模型生成回答。知识库的检索能力直接决定回答质量。
传统数据库做不了语义检索。用户搜"手机续航差"，关系型数据库只能在标题或描述字段做关键词匹配，"电池不耐用"这种语义相同但用词不同的内容完全匹配不到。向量数据库的做法是先把所有文档通过Embedding模型转成高维向量，查询时同样把用户问题转成向量，然后在向量空间里计算余弦距离或欧氏距离，找出最相近的Top-K结果。"电池不耐用"和"手机续航差"在向量空间里距离很近，所以能命中。
向量数据库的爆火是大模型落地催生的基础设施需求。它没有突然变强，是它等的场景来了。
底层机制的差异：不是升级版，是完全不同的东西
很多人以为向量数据库是传统数据库加了向量功能。但实际是它们从底层设计上，就不是同一个物种。
存储结构上，关系型数据库按行或列组织数据，每个字段有明确的类型定义。VARCHAR存字符串，INT存整数，DECIMAL存金额。这种设计的优势是数据含义清晰，做聚合、排序、关联都有明确的语义。向量数据库存储的是高维浮点数数组，一个768维的Embedding就是768个float32。这些数字本身没有业务含义，只有向量之间的距离才有意义。你没法对一个768维向量做GROUP BY，也没法对它做范围查询。
索引机制差异更大。关系型数据库的核心索引是B+树，本质是有序树结构，叶子节点按key值排序并用双向链表连接。这种结构天然适合精确查找和范围扫描。WHERE id = 100走主键索引，O(log N)时间定位到叶子节点。WHERE price BETWEEN 100 AND 200走范围扫描，从左边界开始沿链表向右遍历。Hash索引对等值查询是O(1)，但不支持范围查询。
向量数据库的索引是ANN（Approximate Nearest Neighbor）算法，主流有HNSW和IVF两种。HNSW构建多层图结构，每层是下一层的子集。查询时从顶层做贪心搜索找到最近节点，然后逐层向下细化。召回率可以做到99%以上，百万级向量毫秒级返回，代价是内存占用大，数百万向量可能占用10GB以上的RAM，图的构建和更新成本高。IVF先把向量空间用K-Means聚类成N个簇，查询时只搜索距离最近的几个簇。配合PQ（Product Quantization）可以把向量压缩到几十字节，适合十亿级规模，但召回率会下降。
查询执行上，关系型数据库走"条件过滤+排序+限制"的执行计划。优化器根据统计信息选择索引，过滤掉不符合WHERE条件的行，然后ORDER BY排序，LIMIT截断。整个过程是确定性的，同样输入一定有同样输出。向量数据库走"距离计算+Top-K排序"，对查询向量和候选向量做距离计算，按距离升序取前K个。这个过程是近似的，不同参数设置会得到不同的结果集。
| 维度 | 关系型数据库 | 向量数据库 |
|---|---|---|
| 存储结构 | 行/列结构，字段有明确类型定义 | 高维浮点数数组，数值本身无业务含义 |
| 核心索引 | B+树（精确+范围），Hash（等值O(1)） | HNSW（图遍历，高召回），IVF-PQ（聚类+压缩，大规模） |
| 查询语义 | WHERE过滤+ORDER BY+LIMIT，确定性结果 | 距离计算+Top-K排序，近似结果 |
| 事务保障 | ACID完整，支持回滚和隔离级别 | 部分产品提供ACID，多数仅支持最终一致性 |
| 内存模型 | Buffer Pool缓存热点页，冷热分层 | HNSW图需全量加载内存，IVF可部分加载 |
理解了这些差异，替代论为什么不成立就清楚了。关系型数据库的价值在事务一致性和结构化查询，银行转账、订单管理、权限控制这些场景ACID是底线。向量数据库的价值在高维相似度检索，RAG、推荐召回、图片去重这些场景B+树根本做不了。
我以前也犯过类似的认知错误。刚接触MongoDB的时候觉得文档模型比关系模型灵活，不用定义Schema就能存数据，关系型数据库迟早被淘汰。后来在一个需要多表关联加事务的场景里用了MongoDB，关联逻辑全写在应用层，事务靠应用代码兜底，出了问题排查极其痛苦。最后换回关系型数据库，用JOIN和事务把逻辑收拢，代码量减少了一半。从那之后我学乖了，判断一个技术能不能替代另一个，先看底层机制能不能覆盖核心需求。
真正的趋势是融合，不是替代
最近的数据库动态里，融合的信号已经很明显。传统数据库在加向量能力，MySQL从8.0.31开始支持VECTOR数据类型和距离函数，8.4.0首次引入原生HNSW索引，9.0进一步完善了向量支持。PostgreSQL的pgvector扩展成了社区标配，2025年经过现代SSD优化后，查询吞吐量提升最高可达11倍，索引构建时间缩减超过98%，百万向量规模下召回率可达98.5%。不少云厂商的关系型数据库产品也上线了向量检索功能。向量数据库也在补关系型能力，Milvus从2.1.0版本就引入了标量过滤，2.4版本增加了SQL语法检索能力，Qdrant在1.13.0版本切换到mmap存储提升效率，2.8.0版本增加了稀疏向量索引。
大多数业务同时需要精确查询和语义检索，用两套系统增加运维成本和一致性风险。多模数据库的思路是用一套引擎支撑多种数据模型，应用层少对接一个组件，数据同步的问题也少了。
我做过的一个电商推荐系统就是这种架构。用户画像、商品元数据、交易记录放在关系型数据库里做精确查询和事务管理，商品描述和评论的Embedding放在向量数据库里做相似度召回。推荐流程是向量库先召回Top-200候选商品，关系型数据库根据价格、库存、地域等条件做精确过滤，最后返回排序结果。两个库通过商品ID关联，数据同步用Binlog实时推送。
这套架构跑了半年，稳定。但有个细节值得说。向量库召回的200个商品经过关系型数据库过滤后可能只剩十几个。如果过滤条件太严格，召回率再高也没用。设计推荐流程时，向量召回和关系型过滤的条件要一起做A/B测试，不能各调各的。这个坑我们踩过，调参花了两周。
选型时怎么判断
先看数据特征。结构化的事实记录选关系型，用户表、订单表、权限表这种有明确字段定义和业务逻辑的数据，关系型数据库的Schema约束和数据类型检查能规避大量脏数据问题。非结构化的特征表示考虑向量，文本Embedding、图片特征向量、音频特征这种高维浮点数组，关系型数据库存不了也查不快。两种数据都有就都上，别试图用一个系统解决所有问题。
再看查询模式。精确条件筛选走B+树，WHERE user_id = 100 AND status = 'active'，关系型数据库的主键索引和复合索引能在毫秒级定位目标行。相似检索走ANN算法，"找与这段文本最相似的10条记录"，向量数据库的HNSW索引是正确选择。混合查询优先考虑向量库的标量过滤能力，或者关系型数据库先过滤再调向量库检索，具体取决于数据量和过滤率。
最后看一致性要求。金融交易、库存扣减、权限变更必须用关系型数据库，ACID是底线。搜索推荐、内容召回可以放宽一致性要求，向量数据库的最终一致性模型足够用。需要强一致性的业务把核心数据放在关系型数据库，只需要最终一致性的同步数据放在向量库，两边用可靠的同步机制连接。
普通增删改查加全文搜索的场景别急着上向量数据库，关系型数据库的全文索引和模糊查询够用。做RAG应用、语义搜索、推荐召回，向量数据库是必选项，但关系型数据库也别丢，用户、权限、订单这些核心业务数据必须靠它来管。两种需求都有优先考虑多模数据库方案，运维成本更低。多模数据库在中等规模场景下的向量性能已经接近专用库，差距在可接受范围内，但在纯向量检索性能、分布式能力和技术成熟度上仍略逊于专用向量数据库。选型前一定要用真实数据量和查询模式做基准测试。
避坑清单
向量数据库只擅长一件事，在向量空间里找最近的邻居。出了这个能力范围，聚合查询、多表关联、复杂条件过滤都不如关系型数据库成熟。别因为它在RAG场景里表现好，就想用它替代所有数据存储。
HNSW的M、efConstruction和ef参数直接影响召回率和查询延迟。M控制每个节点的最大连接数，efConstruction控制构建时的搜索范围，ef控制查询时的搜索范围。M和efConstruction越大召回率越高，但构建时间和内存占用也越大。我见过一个项目拿默认配置上了生产，1000万向量规模下查一次要3秒。这些参数必须根据数据量和精度要求调过再上线，建图完成后很难在线调整。另外HNSW索引构建时内存消耗可能非常大，数百万向量可能占用10GB以上的RAM，规划服务器配置时要留足余量。
关系型数据和向量数据分库存储时提前规划好关联方式和数据同步机制。最常见的坑是数据不同步。关系型数据库里的商品下架了，向量库里还在被召回。用Binlog或CDC做实时同步是最稳妥的方案，定时批处理同步在数据量大了之后延迟会越来越大。
MySQL和PostgreSQL的向量能力是后来加的，大规模场景下性能和专业向量数据库仍有差距。不过pgvector经过2025年的优化，与专用向量库的差距已缩小到20%-30%以内。关系型数据库的向量检索走的是全量扫描或小规模ANN，数据量超过百万级后延迟明显上升。上生产前一定要用真实数据量做全量压测，别拿测试环境的几千条数据测出来的QPS当参考。
向量数据库的兴起会终结传统数据库吗？不会。关系型数据库跑了四十年，经历过NoSQL冲击、云原生浪潮，到现在还是企业核心业务系统的基石。每次新技术出来都有人喊替代，每次喊完关系型数据库还是在那里。
你手里的技术栈能不能覆盖当下的业务需求，这才是该关注的事。你的项目里用到向量数据库了吗？踩了哪些坑？欢迎在评论区聊聊。
我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋
