把embedding数据存进PostgreSQL并用pgvector做相似度检索，是很多团队在搭建RAG或者推荐系统时的选择。它省去了额外部署一套专用向量数据库的运维成本，事务、备份、权限管理都能复用现有的PostgreSQL体系。但默认配置下的pgvector表现往往不尽如人意：几十万条数据量下一次查询延迟可能达到几百毫秒，数据量再往上走，顺序扫描的代价会指数级放大。这篇文章从索引原理、参数配置、查询写法三个层面，系统讲清楚pgvector的性能调优思路。
一、先搞清楚：为什么默认情况下向量查询这么慢
pgvector安装后如果不建索引，任何相似度查询都会退化成全表顺序扫描。假设你有一张100万行的表，向量维度是1536（OpenAI embedding的常见维度），每一行的向量数据大约占用6KB。一次查询意味着数据库要把将近6GB的数据从磁盘读出来，逐行计算距离，这个代价在机械盘上是灾难性的，在SSD上也不轻松。
顺序扫描慢的另一个原因在于距离计算本身。pgvector支持三种距离度量：<->（L2距离）、<-#>（内积）、<=>（余弦距离）。每种距离都需要对两个向量做逐维运算，维度越高计算量越大。1536维的向量算一次余弦距离，相当于上千次浮点乘加。虽然pgvector内部用了SIMD指令加速，但架不住数据量乘以维度的双重放大。
可以用EXPLAIN ANALYZE直观感受一下：
EXPLAIN ANALYZE SELECT id, content <-> '[0.1, 0.2, ...]' AS distance FROM items ORDER BY content <-> '[0.1, 0.2, ...]' LIMIT 10;
如果执行计划里出现的是Seq Scan on items加上Sort，延迟数字大概率在几百毫秒以上。这就是没有索引的状态，也是一切调优的起点。
二、索引选型：IVFFlat与HNSW的原理和取舍
pgvector提供了两种近似最近邻索引：IVFFlat和HNSW。理解它们的原理，才能在召回率和速度之间做出正确取舍。
IVFFlat：聚簇倒排思路
IVFFlat的核心思想是先用K-means把整个向量空间切成若干个簇（list），查询时只计算查询向量落在哪个簇里，然后只扫描该簇以及相邻少数几个簇中的向量。这样把全量扫描变成了局部扫描，速度提升明显，代价是可能漏掉落在其他簇里的近邻，产生召回率损失。
构建IVFFlat索引的关键参数是lists，即簇的数量。官方建议的经验值是rows / 1000，数据量到百万级以上可以用sqrt(rows)。查询时还有一个probes参数，控制扫描多少个簇，值越大召回率越高但越慢：
-- 构建索引，1536维向量，余弦距离 CREATE INDEX ON items USING ivfflat (content vector_cosine_ops) WITH (lists = 1000); -- 查询前设置探测簇数量 SET ivfflat.probes = 10;
IVFFlat有一个容易被忽视的坑：索引构建依赖训练数据，所以必须在表里已有相当数量的数据之后再建索引。在空表上建IVFFlat索引，聚类质量会很差，召回率惨不忍睹。数据大幅增长后，也应该考虑重建索引让聚类中心重新分布。
HNSW：分层跳表思路
HNSW是一种基于图的索引，它构建一个多层近邻图，上层稀疏、下层稠密。查询时从顶层入口快速定位到大致区域，逐层下沉做贪心搜索，在最底层精细查找近邻。它的查询速度通常显著快于IVFFlat，召回率也更高，代价是构建速度慢、索引体积大。
HNSW有两个核心参数：m控制每个节点在图中的连接数（默认16，越大召回越高、内存占用越大），ef_construction控制建索引时的搜索深度（默认64，越大索引质量越好但建得越慢）。查询时用hnsw.ef_search控制搜索范围：
CREATE INDEX ON items USING hnsw (content vector_cosine_ops) WITH (m = 16, ef_construction = 200); -- 查询时提高搜索深度，换取召回率 SET hnsw.ef_search = 100;
两者的选择建议很直接：如果索引可以慢慢建、内存充裕，优先选HNSW；如果写入频繁、需要快速重建索引，或者数据集不大，IVFFlat是更务实的选择。另外要注意，HNSW索引在pgvector 0.5.0之后才引入，老版本需要先升级扩展。
三、参数配置与查询写法优化
系统层面的配置
向量索引对内存非常敏感。HNSW索引基本要常驻内存才能发挥性能，如果索引被换出到磁盘，延迟会出现数量级的退化。需要重点关注shared_buffers和effective_cache_size，后者告诉优化器有多少内存可以用于缓存，建议设置为物理内存的50%到75%。此外，maintenance_work_mem决定了建索引时能用的内存，默认64MB太小，建HNSW索引时建议临时调大到几个GB，能明显缩短构建时间。
-- 建大索引前临时调整 SET maintenance_work_mem = '4GB'; CREATE INDEX ON items USING hnsw (content vector_cosine_ops); RESET maintenance_work_mem;
查询层面的注意事项
近似索引有一个重要限制：当查询带有ORDER BY ... LIMIT k时性能最好，一旦和复杂过滤条件组合，优化器可能放弃索引。pgvector从0.8.0开始支持迭代式索引扫描，能在过滤后仍走索引，遇到“向量检索+条件过滤”场景时务必确认版本。写法上还要注意，距离表达式要和索引的操作符类严格一致，比如索引用的是vector_cosine_ops，查询就必须用<=>操作符，用错操作符会导致索引完全不生效，这是实际项目中最高频的踩坑点之一。
召回率怎么验证
调优不能只看延迟，召回率同样重要。做法是取一批查询，分别用索引查询和精确查询（顺序扫描）取top-k结果，计算两者的重合比例。如果召回率低于95%，可以逐步调大hnsw.ef_search或ivfflat.probes，观察延迟和召回率的变化曲线，找到符合业务容忍度的平衡点。检索类业务一般要求召回率在95%以上，推荐场景有时90%也可接受。
总结一下调优路径：先建对索引并匹配正确的操作符，再根据数据规模调索引构建参数，然后通过查询参数在速度和召回之间找平衡，最后确认内存配置让索引常驻缓存。按这个顺序走下来，百万级数据的向量查询延迟通常能稳定在10毫秒以内，足以支撑绝大多数在线检索场景。
PostgreSQLpgvector向量查询优化修改时间：2026-09-09 01:08:53