id revival 的 Mongodb 分页 - 它是一种反模式吗？

Question

这种问题以前有人问过，我也问过，但我还是想不通。

因此，Mongo 按 id 以自然顺序存储文档（据我所知，这是写入磁盘的物理顺序？），并且每个文档（几乎）都有一个大于上一个的 id。伟大的。因此，假设我们在一个集合中有 11 个文档，每个整数代表按自然排序顺序的每个 id，例如 [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11]。让我们假设文档是数组。

假设我们要在没有其他查询参数的情况下对所有这些文档进行分页，以 5 页为单位。

所以我们执行并得到：

db.foo.find().limit(5) - [1] [2] [3] [4] [5]

db.foo.find({'_id': {'$gt': [5]}}).limit(5) - [6] [7] [8] [9] [10]

db.foo.find({'_id': {'$gt': [10]}}).limit(5) - [11]

到目前为止一切顺利。

这次文档[4] 附加了一堆东西，超出了预先分配的大小限制，所以现在我们的物理/自然（？）排序顺序是[1] [2] [3] [5] [6] [7] [8] [9] [10] [11] [4]

所以我们执行并得到：

db.foo.find().limit(5) - [1] [2] [3] [5] [6]

db.foo.find({'_id': {'$gt': [6]}}).limit(5) - [7] [8] [9] [10] [11]

db.foo.find({'_id': {'$gt': [11]}}).limit(5) - 什么都没有

所以在这种情况下我们跳过[4]?在这种情况下，如果一个文档被删除并在其位置添加一个新文档（通常会变成[12]），也会发生类似的事情。如果我的理解是正确的 - 没有明确指定排序的分页是一种反模式？另一方面，如果您指定排序，那是否意味着您仍然必须访问集合中的每个文档然后对它们进行排序？

Answer 1

如果您按索引排序，则不必访问所有文档。

在 MongoDB 中，排序操作可以通过检索来获取排序顺序 基于索引中的排序的文档。如果查询计划器 无法从索引中获取排序顺序，它将对结果进行排序 在记忆中。使用索引的排序操作通常有更好的 性能优于不使用索引的那些。另外，排序 不使用索引的操作将在使用 32 时中止 兆字节的内存。

https://docs.mongodb.com/manual/tutorial/sort-results-with-indexes/