pgvector索引使用中的常见误区与优化方案

在使用pgvector进行向量相似度搜索时，索引的正确使用对查询性能至关重要。本文将深入分析一个典型场景：当查询中包含WITH子句(CTE)时，为什么向量索引可能不会被使用，以及如何优化这类查询。

问题现象

在pgvector中，当我们执行简单的向量相似度查询时，索引通常会被正确使用。例如：

EXPLAIN SELECT * FROM incident_embedding 
ORDER BY embedding <=> '[1,2,3]' LIMIT 5;

这个查询会利用incident_embedding_embedding_idx索引进行高效的KNN搜索。然而，当我们将查询改写为使用WITH子句的形式时：

EXPLAIN WITH v AS (
    SELECT embedding as vec 
    FROM incident_embedding 
    WHERE incident_id = 2491825880941960244
)
SELECT *, embedding <=> v.vec as distance 
FROM incident_embedding, v 
ORDER BY embedding <=> v.vec LIMIT 5;

此时查询计划显示pgvector没有使用索引，而是进行了全表扫描，这在大型数据集上会导致严重的性能问题。

原因分析

这种现象的根本原因在于PostgreSQL查询规划器的限制。规划器无法自动将这种包含CTE和连接的查询转换为"先获取单个向量，再基于该向量进行KNN搜索"的最优执行计划。

具体来说：

1. 规划器将CTE视为一个独立的关系(relation)
2. 在处理连接时，它没有特殊的逻辑来识别这种"先获取参考向量，再进行相似度搜索"的模式
3. 因此，它选择了嵌套循环连接+排序这种通用但低效的执行方式

解决方案

方案1：使用子查询显式控制执行顺序

EXPLAIN WITH v AS (
    SELECT embedding as vec 
    FROM incident_embedding 
    WHERE incident_id = 2491825880941960244
)
SELECT *, embedding <=> (SELECT v.vec from v) as distance 
FROM incident_embedding 
ORDER BY embedding <=> (SELECT v.vec from v) LIMIT 5;

这种方法通过子查询强制PostgreSQL先执行CTE获取参考向量，然后再基于该向量进行索引扫描。查询计划会显示正确的索引使用情况。

方案2：避免使用CTE，直接使用子查询

EXPLAIN SELECT *, embedding <=> (
    SELECT embedding FROM incident_embedding 
    WHERE incident_id = 2491825880941960244
) as distance 
FROM incident_embedding 
ORDER BY distance LIMIT 5;

这种写法更加直接，通常也能获得理想的执行计划。

性能影响

在包含100万向量的测试数据集上：

• 使用索引的查询响应时间通常在10-100ms级别
• 不使用索引的全表扫描查询可能需要数秒甚至更长时间
• 差异随着数据量增长而指数级扩大

最佳实践建议

1. 对于KNN查询，尽量使用简单的查询形式
2. 当需要动态获取参考向量时，优先考虑子查询而非CTE
3. 使用EXPLAIN验证查询计划，确保索引被正确使用
4. 对于复杂查询，考虑将其拆分为多个简单查询
5. 在应用层获取参考向量，然后将其作为参数传递给KNN查询

结论

pgvector的索引功能强大，但需要正确的查询写法才能发挥最大效用。理解查询规划器的工作原理，并适当调整查询结构，可以显著提高向量相似度搜索的性能。特别是在使用CTE等高级SQL特性时，更需要注意索引的使用情况。