🚀 引言：为什么 Top-K 查询在 Postgres 中变慢了？

“给我最匹配的 10 条结果”，这听起来像是一个再简单不过的 SQL 需求。但在 PostgreSQL 中，一旦你尝试在同一个查询中加入文本搜索（BM25 评分）、过滤条件和排序，性能往往会急剧下降。

传统的 Postgres 索引在面对这类场景时存在天然的“鱼与熊掌”困境：

—

🔍 传统方案的性能痛点

在标准 Postgres 中，执行带有 ORDER BY score DESC LIMIT 10 的查询通常会经历以下瓶颈：

全量评分：为了找到前 10 名，Postgres 可能需要对数百万匹配行进行评分。
堆栈排序 (Top-N Heapsort)：虽然 Postgres 使用堆排序来优化 LIMIT，但如果基础扫描（如 GIN 扫描）不支持顺序读取，它仍需扫描大量行才能填充该堆栈。
索引失效：当过滤条件和排序字段不在同一个复合索引中时，优化器往往被迫选择效率较低的 Bitmap Heap Scan。

—

ParadeDB 提出了一种更高效的架构来重写 Top-K 的处理逻辑：

不再分离搜索和排序。ParadeDB 的索引结构允许在遍历索引的同时，直接利用列式存储（Columnar Storage）获取排序键或评分权重，从而在一次扫描中完成过滤和排序。

利用 Tantivy（其底层搜索引擎库）的特性，ParadeDB 实现了 TopDocs Collector。它使用快速选择算法（Quickselect）维护一个固定大小的缓冲区（Top-N），在遍历索引流时实时淘汰低分文档，极大减少了内存占用和 I/O 开销。

在处理 WHERE status = 'active' ORDER BY score DESC LIMIT 10 时，优化后的执行器能够：

—

如果你暂时无法迁移到 ParadeDB，可以尝试以下 Postgres 原生优化技巧：

—

想了解更多关于 Postgres 极致性能调优的内容吗？欢迎在评论区留言讨论！