如何优化搭载pgvector的PolarDB中属性过滤+向量相似度混合查询性能？

一、针对性优化建议 #

1. 给HNSW索引附加属性列（INCLUDE） #

创建包含过滤属性的HNSW索引，让数据库在遍历向量索引时直接过滤属性条件，无需回表查询无效数据，大幅减少候选集的无效计算：

CREATE INDEX idx_embedding_hnsw_inc ON myTable USING hnsw (embedding) INCLUDE (user_name, status);

查询时数据库会优先从索引中获取向量候选，同时检查user_name和status是否符合条件，跳过不符合的条目，避免后续无效的距离计算。

2. 调整HNSW检索参数 #

增大hnsw.ef_search参数（默认值为40），让HNSW检索时返回更多候选向量，确保在过滤属性后仍能获取足够的符合条件的近邻结果，避免因候选不足导致的多次检索开销：

-- 仅当前会话生效
SET LOCAL pgvector.hnsw.ef_search = 200;

-- 执行查询
SELECT * 
FROM myTable 
WHERE user_name = 'nameabc' AND status = 'active'
ORDER by embedding <=> '[2.0, 3.0 ...]'::vector
LIMIT 100;

可根据实际数据分布调整ef_search值（建议范围100-500），平衡检索精度和速度。

3. 基于分区表缩小检索范围 #

按过滤属性（如user_name或status）对表进行分区，让属性过滤直接定位到目标分区，再在分区内使用HNSW索引做向量检索：

-- 按status列表分区示例
CREATE TABLE myTable (
    id INT,
    user_name VARCHAR(50),
    status VARCHAR(20),
    embedding vector(1536)
) PARTITION BY LIST (status);

-- 创建active分区及对应HNSW索引
CREATE TABLE myTable_active PARTITION OF myTable FOR VALUES IN ('active');
CREATE INDEX idx_embedding_hnsw_active ON myTable_active USING hnsw (embedding);

分区后，属性过滤status = 'active'会直接路由到myTable_active分区，检索范围从1000万缩小到该分区的数据量，向量检索效率大幅提升。

4. 优化全量距离计算的CPU负载 #

如果必须先通过B-tree过滤再计算向量距离，可通过并行查询分散CPU压力：

-- 开启并行查询（根据服务器CPU核数调整）
SET LOCAL max_parallel_workers_per_gather = 4;

WITH filtered AS (
    -- 仅选择必要列，减少数据传输开销
    SELECT id, user_name, status, embedding
    FROM myTable 
    WHERE user_name = 'nameabc' AND status = 'active'
)
SELECT *
FROM filtered
ORDER BY embedding <=> '[2.0, 3.0 ...]'::vector
LIMIT 100;

同时避免使用SELECT *，只返回业务需要的列，降低数据处理的CPU消耗。

二、混合索引方案 #

目前PolarDB for PostgreSQL结合pgvector支持以下两种混合索引实现：

1. 带INCLUDE属性的HNSW索引 #

如前文所述，通过INCLUDE子句将过滤属性附加到HNSW向量索引中，本质是实现“向量索引+属性列”的混合存储，支持在索引内完成属性过滤，无需回表。这是当前最实用的混合索引方案，兼顾向量检索效率和属性过滤的精确性。

2. 复合索引（不推荐） #

pgvector不支持直接将属性列作为HNSW索引的前缀列，但可以尝试创建B-tree+HNSW的复合索引（需验证PolarDB兼容性）：

-- 仅作示例，实际性能可能不如INCLUDE方案
CREATE INDEX idx_user_status_embedding ON myTable USING btree (user_name, status) INCLUDE (embedding);

但这种方案本质是先通过B-tree过滤属性，再对结果集计算向量距离，和直接使用B-tree索引的效果类似，无法利用HNSW的高效向量检索能力，因此不推荐。

另外，不建议将属性编码到向量中（如拼接低维属性向量），这种方式会损失属性过滤的精确性，且增大向量维度，降低检索效率。

内容的提问来源于stack exchange，提问作者buriedpot