1. 问题现象与场景复现最近在优化一个基于pgvector的语义搜索应用时遇到了一个非常诡异的问题一个原本能正常返回结果的查询在加上ORDER BY子句对向量距离进行排序后竟然返回了空结果集。这完全违背了直觉——排序操作理论上不应该影响数据的存在性它只是改变了数据的呈现顺序。具体场景是这样的我们有一个documents表其中包含一个名为embedding的向量列使用pgvector的vector(1536)类型存储。业务需求是根据用户输入的查询文本生成对应的向量然后在数据库中查找最相似的文档。最初的查询语句很简单SELECT id, content FROM documents WHERE embedding - [0.1, 0.2, ...]::vector 0.8;这条语句工作得很好能返回所有与查询向量距离小于0.8的文档。但当我们需要取前K个最相似的结果时很自然地会加上ORDER BY和LIMITSELECT id, content FROM documents WHERE embedding - [0.1, 0.2, ...]::vector 0.8 ORDER BY embedding - [0.1, 0.2, ...]::vector LIMIT 10;问题就出在这里。第二条语句在某些情况下会返回空结果而第一条语句明明有数据。更令人困惑的是如果手动计算几个已知文档的向量距离发现它们确实小于0.8理应在结果集中。这个“坑”让我排查了将近一天涉及对pgvector扩展机制、PostgreSQL 查询优化器以及索引使用的深入理解。如果你也在使用向量数据库进行相似性搜索这个经验很可能帮你省下大量调试时间。2. 核心原理pgvector的索引与算子类要理解这个问题的根源必须首先了解pgvector是如何工作的特别是它与 PostgreSQL 索引的集成方式。pgvector提供了几种索引类型来加速向量相似性搜索最常用的是ivfflat倒排文件索引和hnsw分层可导航小世界图。无论哪种索引其核心都是通过一种“近似”算法来快速缩小搜索范围而不是进行全表扫描。当我们创建向量索引时通常会指定一个距离算子比如用于欧氏距离L2的vector_l2_ops或用于余弦相似度的vector_cosine_ops。例如CREATE INDEX ON documents USING ivfflat (embedding vector_l2_ops) WITH (lists 100);这个索引会为embedding - vector这种使用-欧氏距离算子的查询提供加速。这里隐藏的第一个关键点索引是为了加速特定算子的查询而构建的。查询优化器在决定是否使用索引、如何使用索引时会严格检查WHERE子句和ORDER BY子句中使用的算子是否与索引定义的算子类匹配。现在让我们对比一下那两条问题SQL。第一条只有WHERE子句使用了-算子。优化器看到这个条件可能会选择使用我们创建的ivfflat索引进行“索引扫描”快速找到所有距离小于0.8的向量。由于索引扫描本身不保证返回的顺序所以结果的顺序是未定义的但这不影响数据是否存在。第二条SQL在WHERE子句和ORDER BY子句中都使用了-算子。这时优化器面临一个更复杂的决策它需要找到一个既能过滤数据又能排序数据的执行计划。一个理想的计划是使用“索引扫描”因为索引本身可以按照某种顺序尽管不一定是精确的距离顺序组织数据并且能在扫描时应用WHERE过滤条件。然而pgvector的索引尤其是ivfflat是一种近似索引它返回的距离值本身可能就是一个近似值用于快速筛选候选集。问题的核心矛盾就在这里当ORDER BY要求基于精确的距离值排序时优化器可能会认为如果使用近似索引进行扫描无法保证最终排序结果的绝对正确性因为索引提供的距离是近似的。在某些查询规划中优化器可能会因此选择一种更“保守”但最终导致错误结果的执行路径。3. 深度排查执行计划揭示的真相当逻辑推理遇到瓶颈时最有力的工具就是查看数据库的执行计划EXPLAIN和EXPLAIN ANALYZE。通过对比两条SQL的执行计划我发现了决定性的差异。对于第一条只有WHERE的查询其执行计划大致如下Index Scan using documents_embedding_idx on documents Index Cond: (embedding - [0.1, 0.2, ...]::vector 0.8::double precision)这很清晰它使用了我们创建的向量索引进行扫描直接利用索引来评估WHERE条件。对于第二条带ORDER BY的查询其执行计划却变成了这样Sort Sort Key: ((embedding - [0.1, 0.2, ...]::vector)) - Seq Scan on documents Filter: (embedding - [0.1, 0.2, ...]::vector 0.8::double precision)这个计划非常有问题它完全放弃了使用索引转而进行全表扫描Seq Scan。在全表扫描后对所有行计算距离并过滤最后再进行排序。这本身是低效的但还不是返回空集的直接原因。关键在于Filter这一步。当我使用EXPLAIN ANALYZE查看实际执行情况时发现了更诡异的现象- Seq Scan on documents Filter: (embedding - [0.1, 0.2, ...]::vector 0.8::double precision) Rows Removed by Filter: 10000计划显示扫描了10000行但所有行都被过滤掉了Rows Removed by Filter: 10000最终结果就是0行。这怎么可能明明有些行的距离是小于0.8的。这里就是最深的“坑”我怀疑是查询优化器或pgvector扩展在生成执行计划时对于包含ORDER BY的复杂查询可能错误地评估了成本或转换了查询条件导致在计划生成阶段就出现了偏差。另一种可能是在Seq Scan的Filter阶段由于某些内部实现的原因比如向量计算上下文或精度问题距离计算产生了与索引扫描时不同的结果使得本应通过的条件被错误地过滤掉了。注意这种情况与常见的“索引失效”不同。并不是因为函数包装了列如WHERE func(embedding) 0.8导致索引无法使用而是优化器在可以选择索引的情况下主动选择了一个错误的全表扫描路径并且该路径的计算结果出现了偏差。4. 解决方案与最佳实践经过反复测试和查阅资料我总结出了几种解决和规避此问题的方法每种方法都有其适用场景。4.1 方案一使用子查询隔离过滤与排序这是最直接且兼容性最好的解决方案。将过滤WHERE和排序ORDER BY的逻辑分到两个独立的查询阶段。SELECT id, content, distance FROM ( SELECT id, content, embedding - [0.1, 0.2, ...]::vector AS distance FROM documents WHERE embedding - [0.1, 0.2, ...]::vector 0.8 ) AS subquery ORDER BY distance LIMIT 10;为什么有效在子查询中WHERE子句是唯一使用距离算子的地方。优化器在处理这个简单的子查询时会清晰地识别出可以使用embedding列上的索引来加速过滤。子查询执行完毕后得到一个已经过滤好的中间结果集包含计算好的distance列。外层查询只需要对这个明确的distance列进行排序即可这个排序操作与向量索引无关优化器不会产生混淆。这种方法几乎总能得到正确的结果并且通常能利用索引进行高效过滤。4.2 方案二调整查询语法与运算符有时问题可能与查询的写法有关。尝试以下变体变体A为ORDER BY中的计算列显式命名SELECT id, content, embedding - [0.1, 0.2, ...]::vector AS dist FROM documents WHERE dist 0.8 ORDER BY dist LIMIT 10;注意这种写法在部分PostgreSQL版本中可能不被允许因为不能在WHERE子句中直接引用SELECT列表中的别名。但可以尝试有时优化器能更好地理解这种逻辑。变体B使用CTE公共表表达式CTE的逻辑清晰度有时能帮助优化器做出更好的决策。WITH candidate_docs AS ( SELECT id, content, embedding - [0.1, 0.2, ...]::vector AS distance FROM documents WHERE embedding - [0.1, 0.2, ...]::vector 0.8 ) SELECT id, content, distance FROM candidate_docs ORDER BY distance LIMIT 10;其原理与子查询方案类似将过滤阶段封装在CTE内。4.3 方案三检查并优化索引索引配置不当也可能间接引发奇怪的问题。确认索引算子类匹配确保你的索引是为查询中使用的距离算子创建的。如果你的查询用-(L2)索引就应该是vector_l2_ops如果用(内积/余弦)索引就应该是vector_ip_ops或vector_cosine_ops。不匹配会导致索引无法被使用迫使优化器选择其他可能出错的路径。-- 检查现有索引 SELECT indexname, indexdef FROM pg_indexes WHERE tablename documents; -- 确保有类似这样的索引 -- CREATE INDEX ... ON documents USING ivfflat (embedding vector_l2_ops) ...重建或微调索引参数对于ivfflat索引lists参数至关重要。lists数量太少每个列表包含的向量太多导致搜索精度低、速度慢lists数量太多则索引构建慢且可能影响查询规划。如果数据量有较大变化考虑重建索引并调整lists参数。一个经验法则是lists sqrt(行数)但需要根据实际查询性能测试调整。-- 删除并重建索引 DROP INDEX IF EXISTS documents_embedding_idx; CREATE INDEX documents_embedding_idx ON documents USING ivfflat (embedding vector_l2_ops) WITH (lists 1000);考虑使用HNSW索引如果使用的是较旧的pgvector版本0.5.0其ivfflat实现可能在某些边缘情况下有缺陷。hnsw索引通常更稳定、召回率更高虽然创建速度慢、占用空间大但查询性能更好。升级pgvector到最新版本并尝试hnsw索引可能从根本上避免此类问题。CREATE INDEX ON documents USING hnsw (embedding vector_l2_ops);4.4 方案四强制使用索引扫描作为诊断和临时解决方案可以尝试使用pg_hint_plan扩展来强制优化器使用特定的扫描方式。但这属于高级技巧且不推荐在生产中长期使用因为它绕过了优化器的智能选择。首先启用扩展并修改查询LOAD pg_hint_plan; /* IndexScan(documents documents_embedding_idx) */ SELECT id, content FROM documents WHERE embedding - [0.1, 0.2, ...]::vector 0.8 ORDER BY embedding - [0.1, 0.2, ...]::vector LIMIT 10;如果强制索引扫描后查询能返回正确结果那就证实了问题是优化器错误地选择了全表扫描路径。5. 实操心得与避坑指南踩过这个坑之后我总结了几条在pgvector实践中至关重要的经验。心得一始终使用 EXPLAIN ANALYZE 验证查询计划不要相信猜测。任何涉及向量搜索的性能调优或问题排查第一步都应该是查看EXPLAIN ANALYZE的输出。重点关注是否使用了你创建的向量索引查找Index Scan using your_index_name如果没使用索引原因是什么是WHERE条件不匹配还是成本估算问题扫描和过滤的行数是否合理如果Rows Removed by Filter的比例异常高可能就是问题所在。心得二将复杂查询拆解为简单步骤pgvector与 PostgreSQL 优化器的交互有时很微妙。当一个查询同时包含向量距离过滤、排序、分页、连接等其他操作时优化器可能无法生成最优计划。最稳健的做法是遵循“先过滤后处理”的原则使用子查询或CTE利用索引完成核心的向量相似性过滤。在过滤后的结果集上再进行排序、聚合、连接等操作。 这样写出来的SQL可能长一些但逻辑清晰对优化器友好结果也最可预测。心得三保持 pgvector 扩展的更新pgvector是一个活跃开发的开源项目每个版本都在修复bug和提升性能。我遇到的这个“ORDER BY 查不到数据”的问题在早期版本中出现的概率更高。定期检查并升级到稳定版本可以避免很多已知的坑。升级后别忘了根据官方文档的建议测试是否需要重建索引。心得四理解索引的近似本质与召回率无论是ivfflat还是hnsw都是近似最近邻ANN索引。这意味着它们用一定的精度损失换取查询速度。ivfflat的lists和probes参数hnsw的m和ef_construction参数都直接影响召回率即能找到的真正最近邻的比例。当你的查询结果异常少时除了考虑本文提到的优化器问题也要检查是否是索引参数设置过于激进导致召回率太低把本应匹配的结果漏掉了。可以通过暂时禁用索引SET enable_indexscan off;进行全表扫描对比来验证是否是索引召回率的问题。心得五阈值过滤与排序的协同问题这是一个非常隐蔽的坑。你的WHERE子句使用了距离阈值 0.8。请确保你的ORDER BY子句和WHERE子句中计算距离的向量是完全相同的。在我的问题SQL中我重复写了两次向量值。虽然它们值相等但从优化器角度看这是两个独立的表达式。在某些极端情况下这可能导致微妙的差异。最佳实践是使用计算列别名或者子查询确保整个查询中只计算一次距离。这不仅可能避免bug还能提升性能。-- 推荐写法计算一次多处引用 SELECT id, content, distance FROM ( SELECT id, content, embedding - [0.1, 0.2, ...]::vector AS distance FROM documents ) AS subquery WHERE distance 0.8 ORDER BY distance LIMIT 10;这个写法将距离计算放在了子查询的SELECT列表里在WHERE和ORDER BY中引用的是同一个别名distance消除了歧义。 pgvector排序查询返回空集：向量索引与优化器的协同陷阱
1. 问题现象与场景复现最近在优化一个基于pgvector的语义搜索应用时遇到了一个非常诡异的问题一个原本能正常返回结果的查询在加上ORDER BY子句对向量距离进行排序后竟然返回了空结果集。这完全违背了直觉——排序操作理论上不应该影响数据的存在性它只是改变了数据的呈现顺序。具体场景是这样的我们有一个documents表其中包含一个名为embedding的向量列使用pgvector的vector(1536)类型存储。业务需求是根据用户输入的查询文本生成对应的向量然后在数据库中查找最相似的文档。最初的查询语句很简单SELECT id, content FROM documents WHERE embedding - [0.1, 0.2, ...]::vector 0.8;这条语句工作得很好能返回所有与查询向量距离小于0.8的文档。但当我们需要取前K个最相似的结果时很自然地会加上ORDER BY和LIMITSELECT id, content FROM documents WHERE embedding - [0.1, 0.2, ...]::vector 0.8 ORDER BY embedding - [0.1, 0.2, ...]::vector LIMIT 10;问题就出在这里。第二条语句在某些情况下会返回空结果而第一条语句明明有数据。更令人困惑的是如果手动计算几个已知文档的向量距离发现它们确实小于0.8理应在结果集中。这个“坑”让我排查了将近一天涉及对pgvector扩展机制、PostgreSQL 查询优化器以及索引使用的深入理解。如果你也在使用向量数据库进行相似性搜索这个经验很可能帮你省下大量调试时间。2. 核心原理pgvector的索引与算子类要理解这个问题的根源必须首先了解pgvector是如何工作的特别是它与 PostgreSQL 索引的集成方式。pgvector提供了几种索引类型来加速向量相似性搜索最常用的是ivfflat倒排文件索引和hnsw分层可导航小世界图。无论哪种索引其核心都是通过一种“近似”算法来快速缩小搜索范围而不是进行全表扫描。当我们创建向量索引时通常会指定一个距离算子比如用于欧氏距离L2的vector_l2_ops或用于余弦相似度的vector_cosine_ops。例如CREATE INDEX ON documents USING ivfflat (embedding vector_l2_ops) WITH (lists 100);这个索引会为embedding - vector这种使用-欧氏距离算子的查询提供加速。这里隐藏的第一个关键点索引是为了加速特定算子的查询而构建的。查询优化器在决定是否使用索引、如何使用索引时会严格检查WHERE子句和ORDER BY子句中使用的算子是否与索引定义的算子类匹配。现在让我们对比一下那两条问题SQL。第一条只有WHERE子句使用了-算子。优化器看到这个条件可能会选择使用我们创建的ivfflat索引进行“索引扫描”快速找到所有距离小于0.8的向量。由于索引扫描本身不保证返回的顺序所以结果的顺序是未定义的但这不影响数据是否存在。第二条SQL在WHERE子句和ORDER BY子句中都使用了-算子。这时优化器面临一个更复杂的决策它需要找到一个既能过滤数据又能排序数据的执行计划。一个理想的计划是使用“索引扫描”因为索引本身可以按照某种顺序尽管不一定是精确的距离顺序组织数据并且能在扫描时应用WHERE过滤条件。然而pgvector的索引尤其是ivfflat是一种近似索引它返回的距离值本身可能就是一个近似值用于快速筛选候选集。问题的核心矛盾就在这里当ORDER BY要求基于精确的距离值排序时优化器可能会认为如果使用近似索引进行扫描无法保证最终排序结果的绝对正确性因为索引提供的距离是近似的。在某些查询规划中优化器可能会因此选择一种更“保守”但最终导致错误结果的执行路径。3. 深度排查执行计划揭示的真相当逻辑推理遇到瓶颈时最有力的工具就是查看数据库的执行计划EXPLAIN和EXPLAIN ANALYZE。通过对比两条SQL的执行计划我发现了决定性的差异。对于第一条只有WHERE的查询其执行计划大致如下Index Scan using documents_embedding_idx on documents Index Cond: (embedding - [0.1, 0.2, ...]::vector 0.8::double precision)这很清晰它使用了我们创建的向量索引进行扫描直接利用索引来评估WHERE条件。对于第二条带ORDER BY的查询其执行计划却变成了这样Sort Sort Key: ((embedding - [0.1, 0.2, ...]::vector)) - Seq Scan on documents Filter: (embedding - [0.1, 0.2, ...]::vector 0.8::double precision)这个计划非常有问题它完全放弃了使用索引转而进行全表扫描Seq Scan。在全表扫描后对所有行计算距离并过滤最后再进行排序。这本身是低效的但还不是返回空集的直接原因。关键在于Filter这一步。当我使用EXPLAIN ANALYZE查看实际执行情况时发现了更诡异的现象- Seq Scan on documents Filter: (embedding - [0.1, 0.2, ...]::vector 0.8::double precision) Rows Removed by Filter: 10000计划显示扫描了10000行但所有行都被过滤掉了Rows Removed by Filter: 10000最终结果就是0行。这怎么可能明明有些行的距离是小于0.8的。这里就是最深的“坑”我怀疑是查询优化器或pgvector扩展在生成执行计划时对于包含ORDER BY的复杂查询可能错误地评估了成本或转换了查询条件导致在计划生成阶段就出现了偏差。另一种可能是在Seq Scan的Filter阶段由于某些内部实现的原因比如向量计算上下文或精度问题距离计算产生了与索引扫描时不同的结果使得本应通过的条件被错误地过滤掉了。注意这种情况与常见的“索引失效”不同。并不是因为函数包装了列如WHERE func(embedding) 0.8导致索引无法使用而是优化器在可以选择索引的情况下主动选择了一个错误的全表扫描路径并且该路径的计算结果出现了偏差。4. 解决方案与最佳实践经过反复测试和查阅资料我总结出了几种解决和规避此问题的方法每种方法都有其适用场景。4.1 方案一使用子查询隔离过滤与排序这是最直接且兼容性最好的解决方案。将过滤WHERE和排序ORDER BY的逻辑分到两个独立的查询阶段。SELECT id, content, distance FROM ( SELECT id, content, embedding - [0.1, 0.2, ...]::vector AS distance FROM documents WHERE embedding - [0.1, 0.2, ...]::vector 0.8 ) AS subquery ORDER BY distance LIMIT 10;为什么有效在子查询中WHERE子句是唯一使用距离算子的地方。优化器在处理这个简单的子查询时会清晰地识别出可以使用embedding列上的索引来加速过滤。子查询执行完毕后得到一个已经过滤好的中间结果集包含计算好的distance列。外层查询只需要对这个明确的distance列进行排序即可这个排序操作与向量索引无关优化器不会产生混淆。这种方法几乎总能得到正确的结果并且通常能利用索引进行高效过滤。4.2 方案二调整查询语法与运算符有时问题可能与查询的写法有关。尝试以下变体变体A为ORDER BY中的计算列显式命名SELECT id, content, embedding - [0.1, 0.2, ...]::vector AS dist FROM documents WHERE dist 0.8 ORDER BY dist LIMIT 10;注意这种写法在部分PostgreSQL版本中可能不被允许因为不能在WHERE子句中直接引用SELECT列表中的别名。但可以尝试有时优化器能更好地理解这种逻辑。变体B使用CTE公共表表达式CTE的逻辑清晰度有时能帮助优化器做出更好的决策。WITH candidate_docs AS ( SELECT id, content, embedding - [0.1, 0.2, ...]::vector AS distance FROM documents WHERE embedding - [0.1, 0.2, ...]::vector 0.8 ) SELECT id, content, distance FROM candidate_docs ORDER BY distance LIMIT 10;其原理与子查询方案类似将过滤阶段封装在CTE内。4.3 方案三检查并优化索引索引配置不当也可能间接引发奇怪的问题。确认索引算子类匹配确保你的索引是为查询中使用的距离算子创建的。如果你的查询用-(L2)索引就应该是vector_l2_ops如果用(内积/余弦)索引就应该是vector_ip_ops或vector_cosine_ops。不匹配会导致索引无法被使用迫使优化器选择其他可能出错的路径。-- 检查现有索引 SELECT indexname, indexdef FROM pg_indexes WHERE tablename documents; -- 确保有类似这样的索引 -- CREATE INDEX ... ON documents USING ivfflat (embedding vector_l2_ops) ...重建或微调索引参数对于ivfflat索引lists参数至关重要。lists数量太少每个列表包含的向量太多导致搜索精度低、速度慢lists数量太多则索引构建慢且可能影响查询规划。如果数据量有较大变化考虑重建索引并调整lists参数。一个经验法则是lists sqrt(行数)但需要根据实际查询性能测试调整。-- 删除并重建索引 DROP INDEX IF EXISTS documents_embedding_idx; CREATE INDEX documents_embedding_idx ON documents USING ivfflat (embedding vector_l2_ops) WITH (lists 1000);考虑使用HNSW索引如果使用的是较旧的pgvector版本0.5.0其ivfflat实现可能在某些边缘情况下有缺陷。hnsw索引通常更稳定、召回率更高虽然创建速度慢、占用空间大但查询性能更好。升级pgvector到最新版本并尝试hnsw索引可能从根本上避免此类问题。CREATE INDEX ON documents USING hnsw (embedding vector_l2_ops);4.4 方案四强制使用索引扫描作为诊断和临时解决方案可以尝试使用pg_hint_plan扩展来强制优化器使用特定的扫描方式。但这属于高级技巧且不推荐在生产中长期使用因为它绕过了优化器的智能选择。首先启用扩展并修改查询LOAD pg_hint_plan; /* IndexScan(documents documents_embedding_idx) */ SELECT id, content FROM documents WHERE embedding - [0.1, 0.2, ...]::vector 0.8 ORDER BY embedding - [0.1, 0.2, ...]::vector LIMIT 10;如果强制索引扫描后查询能返回正确结果那就证实了问题是优化器错误地选择了全表扫描路径。5. 实操心得与避坑指南踩过这个坑之后我总结了几条在pgvector实践中至关重要的经验。心得一始终使用 EXPLAIN ANALYZE 验证查询计划不要相信猜测。任何涉及向量搜索的性能调优或问题排查第一步都应该是查看EXPLAIN ANALYZE的输出。重点关注是否使用了你创建的向量索引查找Index Scan using your_index_name如果没使用索引原因是什么是WHERE条件不匹配还是成本估算问题扫描和过滤的行数是否合理如果Rows Removed by Filter的比例异常高可能就是问题所在。心得二将复杂查询拆解为简单步骤pgvector与 PostgreSQL 优化器的交互有时很微妙。当一个查询同时包含向量距离过滤、排序、分页、连接等其他操作时优化器可能无法生成最优计划。最稳健的做法是遵循“先过滤后处理”的原则使用子查询或CTE利用索引完成核心的向量相似性过滤。在过滤后的结果集上再进行排序、聚合、连接等操作。 这样写出来的SQL可能长一些但逻辑清晰对优化器友好结果也最可预测。心得三保持 pgvector 扩展的更新pgvector是一个活跃开发的开源项目每个版本都在修复bug和提升性能。我遇到的这个“ORDER BY 查不到数据”的问题在早期版本中出现的概率更高。定期检查并升级到稳定版本可以避免很多已知的坑。升级后别忘了根据官方文档的建议测试是否需要重建索引。心得四理解索引的近似本质与召回率无论是ivfflat还是hnsw都是近似最近邻ANN索引。这意味着它们用一定的精度损失换取查询速度。ivfflat的lists和probes参数hnsw的m和ef_construction参数都直接影响召回率即能找到的真正最近邻的比例。当你的查询结果异常少时除了考虑本文提到的优化器问题也要检查是否是索引参数设置过于激进导致召回率太低把本应匹配的结果漏掉了。可以通过暂时禁用索引SET enable_indexscan off;进行全表扫描对比来验证是否是索引召回率的问题。心得五阈值过滤与排序的协同问题这是一个非常隐蔽的坑。你的WHERE子句使用了距离阈值 0.8。请确保你的ORDER BY子句和WHERE子句中计算距离的向量是完全相同的。在我的问题SQL中我重复写了两次向量值。虽然它们值相等但从优化器角度看这是两个独立的表达式。在某些极端情况下这可能导致微妙的差异。最佳实践是使用计算列别名或者子查询确保整个查询中只计算一次距离。这不仅可能避免bug还能提升性能。-- 推荐写法计算一次多处引用 SELECT id, content, distance FROM ( SELECT id, content, embedding - [0.1, 0.2, ...]::vector AS distance FROM documents ) AS subquery WHERE distance 0.8 ORDER BY distance LIMIT 10;这个写法将距离计算放在了子查询的SELECT列表里在WHERE和ORDER BY中引用的是同一个别名distance消除了歧义。