向量数据库实战指南：pgvector 索引优化与性能调优

1. 从入门到精通：pgvector索引选择与实战场景分析

很多朋友刚开始接触向量数据库时，都会遇到一个核心问题：数据存进去了，查询也写了，但速度就是上不去，尤其是当数据量超过百万级别后，一次简单的最近邻搜索可能要等上好几秒。这其实不是pgvector不行，而是索引没选对、参数没调好。我处理过不少类似的项目，发现大家最容易踩的坑就是直接照搬官方示例的索引创建语句，而忽略了背后的数据特性和业务场景。

pgvector提供了两种核心索引算法：HNSW 和 IVFFlat。你可以把它们想象成两种不同的图书馆管理方法。HNSW像是一个精心构建的、带有多层快速通道的智能图书馆。它建馆（构建索引）耗时很长，也需要占用更大的空间（内存和磁盘），但一旦建好，无论你想找什么书（向量），它都能通过内部的“快速通道”和“跳表”结构，以极快的速度给你找到最相似的那几本，而且准确率（召回率）非常高。它的优点是不需要预先有大量藏书（数据）就能开始设计图纸（创建索引），适合数据动态增长、对查询延迟极其敏感的场景，比如实时的推荐系统或对话式AI的即时响应。

而IVFFlat则像一个传统但高效的图书馆。它首先会把所有书籍（向量）按照主题（聚类中心）分门别类地放到不同的书架（列表）上。找书时，管理员（查询算法）会先判断你想找的书大概属于哪个主题，然后只去那几个相关的书架上找。这种方法建馆速度飞快，占用的空间也小，但缺点是有可能因为判断主题时稍有偏差，导致真正最相关的那本书恰好没在你去翻找的那几个书架上，从而被遗漏（召回率降低）。它特别适合数据相对稳定、写入后不常变更，且对索引构建速度和存储成本有要求的场景，比如归档的历史文档检索、离线的大规模特征库匹配。

这里我分享一个实际调优的案例。我们有一个约500万条768维向量的商品图片特征库，主要用于“以图搜图”。最初我们直接使用了HNSW索引，构建花了近2小时，内存占用也很大，但查询延迟确实能稳定在10毫秒以内。后来业务调整，图片特征库每周才全量更新一次，但需要支持更高并发的查询。我们尝试切换到IVFFlat，通过调整lists（列表数量）和查询时的probes（探测数量）参数，将索引构建时间压缩到了20分钟以内，存储空间减少了约40%。虽然单次查询延迟上升到了20-30毫秒，但通过PostgreSQL的连接池和只读副本，完全支撑住了高峰并发。这个例子说明，没有最好的索引，只有最适合当前场景的索引。

为了帮你快速决策，我整理了这张对比表：