数据库转大模型：向量库选型这件事老本行占便宜

版权与内容来源声明
本文为原创整理。文中涉及官方文档、开源仓库、论文与公开报道的内容，均在附表 A 中标注来源；引用官方原文保持原样，不作改写。文中命令、版本号与界面截图以本文成文时的实测/核验结果为准，标注「待验证」的部分请以你本地环境实际输出为判断依据。本文不推荐任何不合规的软件获取方式，也不对任何收益结果作承诺。转载请注明出处。

第 1 章 · DBA 转大模型，为什么先卡在检索层

1.1 先把概念对齐：向量库到底在干什么

大模型应用里想让模型回答「你自己那堆资料」的问题，通常先走检索增强（RAG，Retrieval-Augmented Generation，意思是先查到相关资料，再让模型基于资料作答）。查资料这一步做的事是：把文档切成小片段，用嵌入模型（Embedding，把一段文字变成一串数字的模型）把每个片段转成向量（vector，就是一串浮点数，比如 768 个数字排成一行）。

向量库（vector database）就是存这些向量、并按「距离最近」把相似片段找回来的库。传统数据库按等值条件或范围条件找行，向量库按「像不像」排序找行——这是两者最本质的差别，也是你换视角的第一站。

DBA 的直觉会立刻跳出来：要找得快，就得建索引。这个直觉是对的，但向量索引和 B 树索引不是一回事，很多转岗的人就是在这里把经验套错了地方。

1.2 老本行能套用的地方，和套不上的地方

下面这张表把两类索引的直觉逐条摆开。左边是你已经形成的判断，右边是套到向量检索时的真实情况。

表 1 · 传统索引直觉与向量索引对照

这张表最后一行值得单独记住：它不是性能问题，而是正确性问题。转到向量库，你要核对的第一件事往往不是"快不快"，而是"结果还对不对"。

1.3 本文给你的是判断顺序，不是产品排名

下面各章按五个维度展开：索引类型、召回质量、内存占用、构建时间、带过滤条件的检索。第 2 章先给总表，之后逐维给阈值，第 6、7 章讲清你原本的优势和反向判据。

第 2 章 · 一张五维选型对照表

2.1 这五个维度是怎么挑出来的

选向量库常见的一种错法，是先看别人推荐哪个产品，再倒过来找理由。更稳的顺序是：先把你的数据形状写成五个可回答的问题，再去挑能满足这些答案的库。这五个问题恰好也是 DBA 每天都在回答的容量、性能、约束、变更和安全问题。

2.2 五维对照总表

表 2 · 向量库选型五维对照（每一维都给出判断阈值）

五维里，①③④是你最有发言权的，⑤几乎就是你的老本行，②是唯一需要补的新知识。

2.3 怎么用这张表

不要五维同时调。建议先卡住 ②（召回质量），因为它是唯一决定"答案对不对"的维；再卡 ③（内存占用），因为它决定你的机器买不买得起；①④⑤是拿到预算和硬件后，再逐个调的工作点。

第 3 章 · 维度一：索引类型，精确还是近似

3.1 精确检索与近似最近邻

精确检索（也叫暴力检索、全量扫描）就是拿查询向量和库里每条向量逐个算距离，结果必然最准，代价是随数据量线性变慢。近似最近邻（ANN，Approximate Nearest Neighbor，意思是牺牲一点准确性换取速度）则通过索引只访问可能相近的一部分数据。

pgvector（PostgreSQL 的向量扩展）官方仓库写得很直白：默认执行精确检索，结果完美召回；一旦加上近似索引，同一个查询会给出不同结果。这句话是理解整件事的钥匙——近似索引是「拿召回换速度」，不是"免费的加速"。

3.2 图索引与倒排式聚类索引各用在哪

主流的近似索引大致分两大族：

• 图索引（HNSW）：HNSW 是 Hierarchical Navigable Small World 的缩写，分层可导航小世界图。人话解释：把向量当成地图上的点，索引预先修好"高速公路"和"小路"，检索时从高速逐层下到小路，几跳就接近目标。论文《Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs》（arXiv:1603.09320）提出的就是这一结构。
• 倒排式聚类索引（IVF）：IVF 是 Inverted File 的缩写，先把向量聚成若干簇，检索时只进最接近的少数几个簇。人话解释：先按"片区"分好类，查的时候只翻最近的几个片区，其余不翻。

表 3 · 两大索引族对照

表 3 的"构建时间更长、内存更多"不是我的判断，而是 pgvector 官方仓库对两种索引的原话对比。Qdrant 官方文档也说明它当前只用 HNSW 作为稠密向量索引，默认 m 为 16、ef_construct 为 100——不同产品的默认值不一样，这正说明参数要按自己数据调，而不能照抄。

3.3 参数怎么起手

以 pgvector 为例，先建表。

⚠️ 代码待验证

-- pgvector：建表，向量维度必须和嵌入模型输出一致
CREATE TABLE docs (
    id        bigserial PRIMARY KEY,
    content   text,
    category  text,
    embedding vector(768)
);

再建 HNSW 索引，给余弦距离用。

⚠️ 代码待验证

-- HNSW：m 与 ef_construction 越大，召回越好、构建越慢、内存越多
CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops)
    WITH (m = 16, ef_construction = 64);

-- 查询期再定搜索候选宽度，越大召回越好、越慢
SET hnsw.ef_search = 100;

如果数据还在持续写、又不想等索引构建，IVF 更合适，但要先有数据再建。

⚠️ 代码待验证

-- IVF：lists 起手值，100 万行以内用 行数/1000，超过 100 万行用 行数的平方根
-- 查询时 probes 起手值约为 lists 的平方根
CREATE INDEX ON docs USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100);
SET ivfflat.probes = 10;

这几个默认值和起手公式都来自 pgvector 官方仓库 README，不是我拍脑袋写的。

第 4 章 · 维度二与维度三：召回质量、内存占用

4.1 召回质量怎么量

召回率（recall）的人话解释是：真正最相近的那些结果里，你的检索找回来了多少。常用指标是 recall@k，即取回来的前 k 条里，命中了多少条本该在前 k 的。

量它的唯一可靠办法，是拿自己的数据跑一遍：先小批量做一次精确检索当"标准答案"，再用近似索引跑同一批查询，比较两者重叠比例。下面是一段流程示意。

⚠️ 代码待验证

# 召回测量流程示意（非完整可运行脚本）
# 1) 用精确检索取标准答案 top_k
# 2) 用近似索引取同一条查询的 top_k
# 3) 计算两者重叠数 / k，即 recall@k
def recall_at_k(exact_ids, approx_ids, k):
    exact_set = set(exact_ids[:k])
    hit = sum(1 for i in approx_ids[:k] if i in exact_set)
    return hit / k

为什么必须用自己的数据测、而不是看公开榜单：向量分布、查询分布、过滤条件都不同，榜单上的默认参数在你这里往往不是好工作点。这不是否定榜单，而是说榜单只能帮你排除，不能替你定参。

表 4 · 召回相关指标该看什么

4.2 内存占用：先粗算，再买机器

DBA 最熟的容量规划在这里可以直接用。粗算公式分两层：

第一层是向量本体：向量条数 × 向量维度 × 每维字节数。pgvector 官方仓库给出更精确的式子：每个向量占「4 × 维度 + 8」字节，且向量最多可到 16000 维；能被 HNSW 索引的 vector 类型最多 2000 维，半精度类型可到 4000 维。

第二层是索引的额外开销，随 m 增大而增加，且 HNSW 的内存占用高于 IVF。

把数字代进去看一遍：

⚠️ 代码待验证

假设：100 万条向量，768 维，用 FP32（每维 4 字节）
本体内存 = 1,000,000 × 768 × 4 字节 ≈ 3.07 GB
换算成半精度（每维 2 字节）≈ 1.54 GB
再加上 HNSW 图结构的额外开销（随 m 增大而增加）
最终常驻内存 = 向量本体 + 索引开销 + 数据库自身开销

表 5 · 内存分项与判断

Milvus 官方文档给了一条容量判据可供参考：大约四分之一原始数据能进内存时，考虑面向磁盘的 DiskANN 以获得更稳定的延迟；全部数据能进内存时，则考虑常驻内存的索引类型。

第 5 章 · 维度四与维度五：构建时间、带过滤检索

5.1 构建时间：批量导入还是增量写入

索引构建和写入会互相抢资源。判断方法很简单：问一句「索引构建速度，跟得上数据到达速度吗」。

表 6 · 批量导入与增量写入的取舍

一句话结论：当索引构建速度跟不上数据到达速度时，先停写、批量建完再开写，比硬扛增量写入更省事。这也是你在传统库里「大表加索引要选维护窗口」的同一套判断。

5.2 带过滤条件的检索：老本行的主战场

这是 DBA 最能占便宜的一维。向量检索常带业务过滤，比如「只在某个分类里找相似片段」。问题在于：过滤和向量检索谁先谁后，结果和性能差很多。

pgvector 官方仓库讲得很清楚：使用近似索引时，过滤是在索引扫描之后才生效的。并且举了一个具体数字——如果一个条件只命中 10% 的行，在 HNSW 默认 hnsw.ef_search 为 40 的情况下，平均只有 4 行能命中。也就是说，你明明只想在某个分类里找 5 条，索引却可能因为过滤发生在后面而返回不足。

pgvector 从 0.8.0 起提供迭代索引扫描，在结果不够时会自动多扫一部分索引。下面是带过滤检索的写法示意。

⚠️ 代码待验证

-- 近似索引下，先看过滤命中比例，再决定是否开迭代扫描
SET hnsw.iterative_scan = relaxed_order;

SELECT id, content
FROM docs
WHERE category = 'tutorial'
ORDER BY embedding <=> '[0.1, 0.2, ...]'   -- 余弦距离，按距离升序
LIMIT 5;

表 7 · 先过滤与后过滤的差别

Milvus 官方文档给了一组可对照的阈值：过滤比例小于 85% 时，图索引通常优于 IVF；比例在 85% 到 95% 之间时用 IVF；比例高于 98% 时用暴力检索最准。Qdrant 官方文档则强调，要让过滤与图检索配合得好，应在写入数据之前先建好 payload 索引，否则需要重建 HNSW 索引。这两条都在说同一件事：过滤不是查询期才想的，它要在建库阶段就规划。

大模型学习路线图：这份资料把从零基础到能自己动手做 Agent 的每一步拆成了阶段表，其中「检索与向量库」一节正好承接本文的五维判断。放在资料包里，扫码即可获取：

第 6 章 · DBA 的三个可直接迁移的优势

6.1 容量规划与索引调优思维

上面第 4 章的粗算公式、第 3 章的参数旋钮，本质都是你做了很多年的「先估容量、再调参数」。向量库只是把「行数 × 行宽」换成了「条数 × 维度 × 字节数」，把「选择度」换成了「过滤命中比例」。你不必重新学一套方法论，只需要把老公式里的变量名换掉。

6.2 事务与一致性

向量库不是只有"搜得快"这一个指标。写上去了但查不到、删了还在结果里、主从读到旧数据，这些你在关系库里天天防的问题，向量库同样存在。判断一个向量库能不能上生产，除了看召回，还要看它的写入可见性、删除语义与一致性模型怎么写。这是很多只从算法视角看向量库的人会漏掉的一层。

6.3 运维与备份

备份、恢复、监控、扩容——这套运维动作在向量库上照样要做，只是对象从数据文件变成了「数据文件 + 索引结构」。近似索引有个额外的坑：重建索引会带来一段可用性下降，所以你得把"重建窗口"纳入运维排期，就像过去给大表加索引要挑时间一样。

第 7 章 · 什么时候不该上专用向量库

7.1 反向判据

转岗的人容易犯的错，是把"新工具"当成"必须用"。向量库也有明确的"不该上"边界。

表 8 · 该不该上专用向量库

7.2 用 PostgreSQL 就够的边界

如果数据在几万条、向量维度也不夸张、业务查询就是"按分类找相似"，那么给现有 PostgreSQL 装一个 pgvector 扩展，通常比另起一套向量库更省事：备份、权限、监控都能复用现有体系。这也是"老本行占便宜"最直接的体现——你不需要换掉熟悉的东西，只需要给表加一个向量列和一个向量索引。

⚠️ 代码待验证

# 在已有 PostgreSQL 上启用 pgvector 扩展（示意）
# 具体安装方式以你的 PostgreSQL 版本与操作系统官方说明为准
psql -d your_db -c "CREATE EXTENSION IF NOT EXISTS vector;"

反过来，当数据量和写入吞吐已经让"表和索引都在同一个库里"变成瓶颈时，再拆出专用向量库才是划算的。

7.3 收个尾

向量库选型这件事，算法背景的人容易从模型和榜单切入，而你从索引、容量、过滤、运维切入，反而更接近生产里真正会出事的地方。要补的新知识其实只有一块：召回怎么量。把这一块补上，剩下的五维里你有四维是现成的。

640 套 AI 大模型行业报告 + 经典 PDF 书籍：里面有大量向量检索与知识库落地的案例拆解，可以和本文的选型判据对着看。放在资料包里，扫码即可获取：

附表 A：本文引用事实与出处对照表

附表 B：术语速查表

写在最后：这篇用到的资料

写这篇文章时，把相关的官方文档和源码又翻了一遍，顺手也整理了几份配套的东西：

• 大模型学习路线图：从零基础到能自己动手做 Agent，按阶段说明每一步该学什么、哪些可以先跳过
• 《LangChain + LangGraph + MCP 智能体开发实战》视频课：7 个模块，从私有化部署、Embedding+RAG 到 MCP+Agent 全流程
• AI 大模型知识库（在线可查）：Agent Skills 从入门到落地、Claude Skills 完全指南等专题，按目录浏览即可
• 640 套 AI 大模型行业报告 + 经典 PDF 书籍：看行业落地案例和别人怎么做的时候用得上
• 大模型零基础到精通教学视频：跟着敲一遍，比只读文档快得多

资料是我自己整理的，放在下面这个码上，扫码即可获取：

添加时备注「AI」，优先通过。

资料按「先路线、再动手、最后查漏」的顺序整理好了，建议先看学习路线那一份，照着它挑一条适合自己当前基础的路径再往下看。