向量数据库是什么？和传统数据库的区别，一篇讲清楚
向量数据库存储、索引、检索的是高维向量（AI 模型把文字、图片、音频转成的那串数字），让你能按"意思"找数据，而不是按"字面"找。传统数据库回答的是"哪些行包含这个词"，向量数据库回答的是"什么内容跟这个最像"。
多数科普文讲到这一句对照就停了。这篇把剩下的路走完：向量库里到底存了什么、同一个查询在两种库里各怎么走、为什么 MySQL 真干不了这活、一张诚实的对比表、什么时候团队会后悔上了向量库，以及真需要时有哪三条路可选。
存的是意思，不是字
一切都从 embedding 模型开始。喂给它一句话、一张图、一段音频，它吐出一长串数字，这就是向量。数字的个数叫维度。没什么玄乎的：颜色就是最直观的向量，红绿蓝三个数定位屏幕上任何一种颜色，一个三维向量而已。embedding 模型做的只是同样的事，把维度从三个换成几百上千个。
妙处在模型把这些数字安排得让"意思变成了几何"。两段话用不同的词说了同一件事，它们对应的点在空间里就挨得很近。IBM 文档里有个经典对照：搜"智能手机"，关键词检索只返回含这四个字的内容；向量检索连" cellphone ""移动设备"也能召回，因为它们的向量落在查询附近。IBM 引用的 2025 年研究还有个数字：向量数据库的采用率一年涨了 377%，是所有大模型相关技术里最快的。这个数字值得停下来想一想：它不是某个小众引擎的炒作，而是整个检索式 AI 浪潮底下的存储层在扩张。
同一个查询，两种走法
抽象定义容易越听越糊，我们拿同一个需求在两种系统里各跑一遍。需求：查公司年假制度的细节。
在传统 SQL 数据库里，文档的元数据躺在表里，你大概会写 WHERE title = '年假制度' 或者 WHERE body LIKE '%休假天数%'。快、精确，而且只要措辞对不上就静默失败。制度文档标题写的是"员工请假与休假管理办法"，里面压根没有"年假"两个字——这行数据永远不会被查出来。做过关键词搜索的开发者都熟悉这个坑：用户输入的是同义词，索引里存的是字面量，两边永远碰不上头。
在向量数据库里，管线两头都不一样。写入时，每份文档已经过 embedding 模型转成向量存进去了。查询时，"查公司年假制度的细节"这句话本身也被转成向量。数据库找出离这个查询向量最近的那些存储向量——"请假与休假管理办法"那份文档就躺在近处，因为"年假"和"休假"意思几乎一样，模型把这层语义编进了数字里。同一个需求，两种失败模式正好相反：精确匹配漏掉换说法的内容，相似检索能接住；反过来，相似检索放弃的，恰是 SQL 引擎打磨了五十年的那些东西（事务、精确聚合、Join），对比表里会写清楚。
为什么 MySQL 真干不了这活
你可能会问：不就是一串数字吗，普通数据库存个浮点数组、算算距离不行吗？技术上可以，而且所有 demo 都这么起步：向量塞进数组，查询时 for 循环挨个算余弦相似度，取前 K 个。几千条数据，跑得飞快。
然后语料涨到一百万条。每次查询都要对一百万个高维向量逐一算相似度。社区里上过线的团队把这条曲线描述得很清楚：单次查询拉长到两三秒，内存一路爬升，并发一来机器直接被压死。数学上没有侥幸，十亿级语料乘上千维向量，暴力遍历回不来。
标准答案是"加索引"。但 B-Tree 索引是为精确查找和有序范围扫描组织的，"找意思最近的向量"既不是等值也不是范围，768 维语义空间里不存在一根能排序的轴。这才是向量数据库真正补的缺口：不是存浮点数，而是为近邻搜索专门建的 ANN 索引（HNSW 图、IVF 聚类、PQ 压缩）。它们天生就是近似的，Pinecone 的工程文档把这个权衡说得很直白：拿一点点精确度换数量级的速度，精确和快之间的旋钮归你调。这些 SQL 引擎里都没有。
向量数据库和传统数据库的区别：一张诚实的表
| 维度 | 传统数据库（MySQL、PostgreSQL） | 向量数据库 |
|---|---|---|
| 数据模型 | 行、列、表，固定 Schema | 高维向量 + 元数据 |
| 查询方式 | 精确：等值、范围、Join、聚合 | "给我最相似的 K 个" |
| 索引 | B-Tree、Hash，为精确和范围而生 | ANN（HNSW、IVF、PQ），为近邻而生 |
| 事务 | 完整 ACID | 通常不支持 ACID，或只有弱一致性 |
| 扩展 | 主从复制、分库分表，要花力气 | 天然分布式 |
| 主场 | 交易、ERP、账户、报表 | 语义搜索、推荐、RAG |
表之外有两句诚实的话。第一，ACID 那一行是真的，不是小字：有生产经验的腾讯云社区作者说得很直白，向量数据库普遍用完整 ACID 换吞吐量，凡是要求银行级一致性的数据，就该待在关系库里。第二，这两类系统是搭档不是对手。成熟的 AI 架构里通常是 PostgreSQL 管账户和订单，向量库管检索，可能再加一个图数据库管实体关系，各干各的活。
什么时候你其实不需要它
每篇科普都讲用例，几乎没人讲翻车的故事，这里补一个。有个团队被大模型的热度带着，做了套"纯向量数据库架构"的电商搜索系统，所有数据全塞进 Milvus。上线第三周，运营提了个日常需求：拉一份"近 7 天购买过 A 商品且收藏过 B 商品的用户"名单做促销。多条件精确筛选，SQL 里一句 WHERE 的事，恰恰是向量引擎干不了的。他们临时写 ETL 把数据倒回 MySQL，两边数据已经不同步，报表数字对不上，最后花了一周重修被删掉的关系型数据层。那篇社区复盘的标题起得很准：追架构时髦，把自己的数据层追没了。
这个故事背后的规则很简单：该用向量库的理由是相似检索这个需求，不是"AI 原生"这个标签。我自己把它记成一句话：先有查询，再有数据库。IBM 自己的文档还补了一类更隐蔽的情况：主题总结、宽泛的主题分析这类任务，模型需要通读全部上下文而不是抓取近邻，向量库帮不上忙。我说得再直接一点：如果你说不出一句以"帮我找最相似的……"开头的需求，你就没有向量问题。
三条落地路径
真有向量问题，路径有三档，多数团队应该从最底下那档起步：
- 检索库，不是数据库。FAISS（Meta 开源）是个相似度检索程序库：快、免费，而且故意不做成数据库，没有权限控制、没有备份、没有多租户。原型验证或单机批处理，选它没错。
- 给现有数据库装插件。PostgreSQL 加 pgvector 扩展，就能在你已经在运维的系统里拥有向量列和 ANN 检索。几十万条向量、中等查询压力，这是新增基础设施最少的路，也是我给已经在跑 Postgres 的团队的默认建议。
- 专用向量数据库。Milvus、Qdrant、Weaviate、Pinecone。什么时候算"配得上"：几千万级向量、高并发查询、需要调优旋钮的团队。一上来就跳到这档，就是上面那家电商团队重修数据层的来路。
行业的趋势是两边在合拢：关系型引擎吸收向量能力，向量引擎补数据库功能。但今天在高并发大规模场景下性能差距仍然真实存在，选哪一档应该跟着你的实际数据量走。
它在 AI 架构里站在哪
读过我们 RAG 详解的话你已经知道，检索那一步负责给大模型喂有依据的上下文，而向量数据库就是那个检索底下的存储引擎。这个依据之所以重要，是因为没有外部知识的生成会漂向编造；一个向量化的知识库是减少 AI 幻觉的实用手段之一，同一条检索管线也是任何够格的 AI 智能体的核心工具。
Cloudflare 的学习中心把"AI 应用为什么绕不开这层"讲得最透：模型记不住训练之外的东西，不存向量的话，每个问题都得把全量语料重新喂一遍：慢、贵，而且反正是塞进模型的上下文窗口，上限摆在那里。向量数据库把这件事变成一次性的 embedding 成本加毫秒级查询。377% 的年增长从这来：它不是 AI 架构的配件，它是记忆本身。
常见问题快答
什么是向量数据库？一句话： 存高维向量（embedding）、按相似度检索的数据库："找最接近的"，而不是按精确匹配查。
向量数据库和传统数据库的区别是什么？ 传统数据库在结构化的行上做精确匹配（等值、范围、Join、完整 ACID）；向量数据库在向量上做近邻检索。是搭档，各管一摊。
它能存普通业务数据吗？ 存的是向量加元数据，多数产品支持按元数据过滤——但一旦需要多条件精确查询、Join 或事务，你需要的是旁边配一个关系库，不是拿它替换。
用 AI 必须自己装一个吗？ 不用。聊天产品和 RAG 服务已经替你做了检索。自己搭向量库的时机，是你要对自己的语料自建检索、且数据量到了 for 循环不好使的那一天。
Milvus、Pinecone、pgvector 是什么？ 三档路径的代表：Milvus 是开源的专用向量数据库，Pinecone 是商业托管版，pgvector 是给你可能已经在跑的 PostgreSQL 加向量检索的那个扩展。
下次有人拿"AI 原生数据库"给你做推荐，你就问一句：我的查询里有哪句是以"找最相似的"开头的？答得上来，再谈选型；答不上来，你缺的不是新数据库，是把 SQL 写好。