优化文档查找：让 Atlas Search 和 Vector Search 提速最高达 5 倍
内容提要
MongoDB优化了Atlas Search和Vector Search的文档查找流程。原实现为每个结果文档重复构建查询计划并获取集合资源，约30%的mongod CPU耗在此处。MongoDB 9.0通过复用参数化SBE执行计划和批量处理文档查找，消除冗余开销，默认启用且无需修改应用。基准测试中$search快4.9倍、$vectorSearch快5.5倍，并发吞吐提升约2.75倍。
延伸解读
性能瓶颈不在检索，而在文档查找的重复准备
文章指出，Atlas Search 和 Vector Search 的查询分为两个阶段：mongot 执行搜索并排序，mongod 根据 _id 查找对应文档。优化前，mongod 为每个结果文档重复构建查询计划并获取集合资源，约30%的 mongod CPU 耗在此处。这意味着瓶颈并非索引查找本身，而是围绕查找的冗余准备工作。结果集越大，重复开销线性增长，成为端到端延迟的重要来源。
两项改动消除冗余：参数化计划复用与批量资源管理
MongoDB 9.0 引入 SbeSingleDocumentLookupExecutor，将查找计划构建一次并缓存，后续仅重新绑定 _id 参数，避免为每个文档重建计划。同时，BatchedEnrichmentStage 缓冲搜索结果，在共享资源范围内批量处理查找，例如1000个文档、批大小100时，集合资源只需获取10次而非1000次。两项优化共同减少了查询解析、优化、计划构建和资源获取释放的开销。
基准提升显著，但需注意测量口径与适用条件
基准测试中，$search 中位延迟从约2.6秒降至527毫秒（4.9倍），$vectorSearch 从3.1秒降至561毫秒（5.5倍）；16并发客户端下吞吐提升约2.75倍。文章明确，约30%的 CPU 开销与近80%的延迟降低是不同测量和工作负载的结果，并非直接比例关系。此外，优化默认启用且无需修改应用，但需运行在 MongoDB 9.0 及支持的配置上。
真实客户负载显示大结果集场景普遍，受益面较广
MongoDB 分析了90天内610个客户集群的1.638亿次 Vector Search 执行，发现至少40%的集群使用21至50的结果限制，至少17%的集群限制超过100。这些较大结果集的查询正是文档查找优化的主要受益对象，因为消除重复计划与资源获取开销的价值随结果文档数量增加而上升。这表明优化不仅限于基准测试，对相当一部分生产负载具有实际意义。
Q&A
MongoDB 9.0 对 Atlas Search 和 Vector Search 做了哪些性能优化？
MongoDB 9.0 优化了文档查找流程，主要做了两件事：一是复用参数化的 SBE 执行计划，避免为每个文档重复构建查询计划；二是批量处理文档查找，通过 BatchedEnrichmentStage 在批次内共享集合资源，减少重复获取和释放资源的开销。这些优化默认启用，无需修改应用。
为什么文档查找会成为 Atlas Search 的性能瓶颈？
原来的 $_internalSearchIdLookup 阶段会为每个匹配的文档单独构建并执行一个聚合子管道，即使查询结构相同、只有 _id 不同，也会重复进行查询解析、优化、执行计划构建以及集合资源的获取和释放。性能分析显示，约 30% 的 mongod CPU 时间花在这些重复的准备工作上，而不是实际检索文档。
优化后 Atlas Search 和 Vector Search 的查询速度提升了多少？
在基准测试中，当返回 10,000 个文档时，Atlas Search 的中位延迟从约 2.6 秒降至 527 毫秒（约 4.9 倍加速），Atlas Vector Search 从约 3.1 秒降至 561 毫秒（约 5.5 倍加速）。在 16 个并发客户端下，吞吐量提升约 2.75 倍，中位延迟降低约 3 倍。
这些优化需要修改应用程序或重建索引吗？
不需要。优化后的文档查找路径在 MongoDB 9.0 中默认启用，应用程序无需重写查询、重建搜索索引或采用新语法。现有的 $search 和 $vectorSearch 管道在支持的配置下会自动受益。
批量处理文档查找是如何减少资源开销的？
通过引入可复用的 BatchedEnrichmentStage，将传入的搜索结果缓冲起来，并在共享的资源作用域内处理。例如，对于 1,000 个文档，如果批大小为 100，集合资源只需获取 10 次，而不是 1,000 次，从而将资源获取和清理的成本分摊到多个查找上。
哪些实际工作负载会从这次优化中受益？
对 610 个客户集群、90 天内 1.638 亿次 Atlas Vector Search 执行的分析显示，至少 40% 的集群执行限制在 21 到 50 之间的查询，至少 17% 的集群执行限制超过 100 的查询。这些返回较大结果集的工作负载尤其受益，因为消除重复的查询计划和资源获取开销在检索更多文档时价值更大。
