pgvector项目中HNSW索引未生效的排查与解决方案

问题背景

在使用pgvector扩展存储向量数据时，开发者经常会遇到HNSW索引未被查询使用的情况。本文以一个实际案例为基础，详细分析如何正确创建和使用pgvector的HNSW索引。

案例详情

某开发者在AWS Aurora Serverless V2环境中使用pgvector存储约1500万条1024维的向量数据，并创建了约90GB大小的HNSW索引。然而在执行相似度查询时，数据库始终使用顺序扫描(seq scan)而非索引扫描。

错误排查过程

初始配置

开发者创建了如下索引：

CREATE INDEX IF NOT EXISTS titan_dims_1024_idx_cosine 
ON public.langchain_pg_embedding 
USING hnsw (((embedding)::public.vector(1024)) public.vector_cosine_ops) 
WHERE (collection_id = 'my-uuid'::uuid);

执行查询时使用了：

SELECT *
FROM langchain_pg_embedding
WHERE collection_id = 'my-uuid'
ORDER BY embedding <=> '[my-vector]'
LIMIT 4;

常见排查手段

开发者尝试了多种方法：

1. 关闭顺序扫描：SET enable_seqscan = off
2. 调整内存参数：SET maintenance_work_mem = '4GB'
3. 增加AWS Aurora的计算单元
4. 检查索引是否确实存在

问题根源

核心问题在于表达式索引的使用方式。当创建索引时使用了类型转换表达式(embedding)::public.vector(1024)，但在查询时直接使用了embedding字段而没有进行相同的类型转换，导致PostgreSQL优化器无法识别该索引适用于此查询。

解决方案

正确的查询方式应该与索引创建时的表达式保持一致：

SELECT *
FROM langchain_pg_embedding
WHERE collection_id = 'my-uuid'
ORDER BY embedding::vector(1024) <=> '[my-vector]'
LIMIT 4;

通过显式添加::vector(1024)类型转换，PostgreSQL优化器就能正确识别并使用HNSW索引。

最佳实践建议

1. 表达式索引一致性：确保查询中的表达式与索引创建时的表达式完全匹配
2. 索引验证：使用EXPLAIN ANALYZE验证查询是否使用了预期索引
3. 类型显式声明：对于向量列，建议在查询中显式声明维度
4. 索引选择性：考虑WHERE条件的选择性，确保索引能有效过滤数据

技术原理

PostgreSQL的表达式索引要求查询必须使用与索引定义完全相同的表达式。这是因为：

1. 优化器通过表达式匹配决定是否使用索引
2. 不同的表达式可能导致不同的语义，即使逻辑上等价
3. 类型转换会影响操作符的选择和优化决策

通过遵循表达式一致性原则，可以确保pgvector的HNSW索引发挥最大效能，显著提升高维向量相似度查询的性能。