为什么我们在 Mongo 中需要一个带有复合索引的额外 LIMIT 阶段

问题描述

我正在使用 Mongo 4.2（坚持这个）并且有一个集合说“product_data”，其中包含具有以下架构的文档：

_id:"2lgy_itmep53vy"
uIdHash:"2lgys2yxouhug5xj3ms45mluxw5hsweu"
userTS:1494055844000

案例 1：有了这个，我就有了集合的以下索引：

1. _id：常规 - 唯一
2. uIdHash：散列

我试图执行

db.product_data.find( {"uIdHash":"2lgys2yxouhug5xj3ms45mluxw5hsweu"}).sort({"userTS":-1}).explain()

这些是结果的阶段：

当然，我可以意识到使用额外的复合索引来避免 mongo 内存中的“排序”阶段是有意义的。

案例 2：现在我试图用现有的索引添加另一个索引 3. {uIdHash:1,userTS:-1}：常规和复合

出乎我的意料，这里的执行结果能够在排序阶段进行优化：

---

---

到目前为止一切都很好，现在我希望在此查询之上构建分页。我需要限制查询的数据。因此查询进一步转换为

db.product_data.find( {"uIdHash":"2lgys2yxouhug5xj3ms45mluxw5hsweu"}).sort({"userTS":-1}).limit(10).explain()

现在每个案例的结果如下：

案例 1 限制结果：

内存中排序的工作量更少（36 个而不是 50 个）并返回预期的文档数量。还不错，阶段性的底层优化不错。

情况 2 限制结果：

令人惊讶的是，在使用索引和查询数据的情况下，处理中添加了一个额外的限制阶段！

我现在的疑惑如下：

1. 当我们已经有 10 个从 FETCH 阶段返回的文档时，为什么我们需要额外的 LIMIT 阶段？
2. 这个额外的阶段会产生什么影响？鉴于我需要分页，我是否应该坚持使用案例 1 索引而不使用最后一个复合索引？

解决方法

Limit 阶段告诉您数据库正在限制结果集。这意味着后续阶段将使用更少的数据。

您关于“为什么我们需要额外的限制阶段”的问题没有意义。 您将查询发送到数据库，并且您不使用（或不需要）任何阶段。 数据库 决定如何完成查询，如果您要求它限制结果集，它会执行此操作，并通过告诉您查询处理中存在限制阶段来通知您它已完成此操作.

,

查询执行器能够执行一些优化。其中之一是当有限制且没有阻塞阶段（如排序）时，当达到限制时，所有上游阶段都可以提前停止。

这意味着如果没有限制阶段，则 ixscan 和 fetch 阶段将在所有 24 个匹配文档中继续进行。

非索引排序没有谨慎的限制阶段，因为它与排序阶段结合在一起。