这种类型的问题以前曾被问过，我也曾问过，但我仍然无法解决。
因此，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]附加了一堆东西，并且超出了预先分配的大小限制，所以现在我们的physycal / natural（？）排序顺序为[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]的新文档，则可能会发生类似的情况。如果我的理解是正确的-没有明确指定排序的分页是一种反模式？另一方面，如果您指定排序，那是否意味着您仍然必须访问集合中的每个文档然后对其进行排序？
答案 0 :(得分：-1)
如果您按索引排序，则不必访问所有文档。
在MongoDB中，排序操作可以通过检索来获得排序顺序 文档根据索引中的顺序排列。如果查询计划者 无法从索引获取排序顺序，它将对结果进行排序 在记忆中。使用索引的排序操作通常会更好 性能要比不使用索引的性能高。另外，排序 不使用索引的操作在使用32时将中止 兆字节的内存。
https://docs.mongodb.com/manual/tutorial/sort-results-with-indexes/