问mongodb中大量记录的分页速度很慢

EN

我连接了两个答案。

问题是，当你使用跳过和限制，没有排序时，它只是按照你向表中写入数据的顺序按表的顺序进行分页，所以引擎需要建立第一个临时索引。最好使用ready _id索引:)您需要使用sort by _id。比使用像这样的大型表要快得多。

db.myCollection.find().skip(4000000).limit(1).sort({ "_id": 1 });

在PHP中，它将是

$manager = new \MongoDB\Driver\Manager("mongodb://localhost:27017", []);
$options = [
            'sort' => array('_id' => 1),
            'limit' => $limit, 
            'skip' => $skip,

        ];
$where = [];
$query = new \MongoDB\Driver\Query($where, $options );
$get = $manager->executeQuery("namedb.namecollection", $query);

我的集合有大约130万个文档(不是那么大)，索引正确，但仍然受到这个问题的很大影响。

在阅读了其他答案之后，解决方案就清晰了；分页集合必须按计数整数排序，该整数类似于SQL的自动增量值，而不是基于时间的值。

问题出在skip上；没有其他方法可以绕过它；如果您使用skip，那么当您的集合增长时，您肯定会遇到这个问题。

使用带有索引的计数整数允许您使用索引进行跳转，而不是跳过。这不适用于基于时间的值，因为您无法计算基于时间的跳转位置，因此在后一种情况下，跳过是唯一的选择。

另一方面，

通过为每个文档分配一个计数编号，写入性能将受到影响；因为所有文档都必须按顺序插入。这对我的用例来说很好，但我知道解决方案并不适合每个人。

最受欢迎的答案似乎不适用于我的情况，但这个答案适用。(我需要能够按任意页码向前查找，而不是一次只查找一个页码。)

此外，如果您正在处理delete，这也很困难，但仍然可能，因为MongoDB支持使用负值的$inc进行批量更新。幸运的是，我不必处理我正在维护的应用程序中的删除。

把这个写下来，写给我未来的自己。用我正在处理的应用程序来解决这个问题可能太麻烦了，但是下一次，如果我遇到类似的情况，我会构建一个更好的。

我将建议一种更激进的方法。将skip/limit (实际上是一种边缘情况)与基于存储桶的排序范围相结合，并且页面不是基于固定数量的文档，而是基于一定的时间范围(或者您的排序方式)。所以你有每个时间范围的顶级页面，如果你需要跳过/限制，你可以在这个时间范围内有子页面，但我怀疑这些存储桶可以足够小，根本不需要跳过/限制。通过使用排序索引，可以避免光标遍历整个库存以到达最后一页。