当前位置：首页 > 问答 > 正文

MongoDB分页怎么搞才快又准，数据多了翻页查找别慌乱

说到MongoDB的分页，尤其是数据量上了千万甚至上亿级别的时候，用不对方法，那体验简直是灾难，页面越点越慢，最后直接超时，用户等得心烦，数据库也被拖垮，咱们今天就来聊聊，怎么才能又快又准地搞定分页,让大数据量下的翻页查找不再慌乱。

第一部分：最常见的“坑”——传统LIMIT OFFSET分页法

很多人刚开始用MongoDB，很自然地会想到用 skip() 和 limit() 来模拟SQL里的 LIMIT OFFSET，你想看第10001条到第10010条数据,你会写：

db.collection.find({}).skip(10000).limit(10)

这个方法在数据量小的时候没问题，但当 skip 的值非常大时，问题就暴露了，根据MongoDB官方文档和其工作原理的普遍认知，skip(10000) 并不意味着数据库直接跳到第10001条记录,它实际要做的是：

你可以想象，当你要跳过100万条数据时，数据库就需要在内存中遍历这100万条记录，这是一个非常昂贵的操作，会消耗大量的CPU时间和内存，数据越多，skip的值越大，速度就越慢，最终导致查询超时，这种方法也被称为“深度分页”问题,是必须要避免的。

第二部分：又快又准的核心方法——基于游标的分页（也叫“寻找法”）

既然“跳过”的效率低下，那最聪明的办法就是“不跳过”，直接“找到”那个位置，这就是基于游标的分页，它利用了数据的天然顺序（通常是基于 _id 或一个时间戳字段）。

核心思路是： 客户端在请求下一页时，不是告诉服务器“跳过多少条”，而是告诉服务器“我从上一次看到的最后一条记录之后开始要”，这就像看书时夹一个书签,下次直接翻到书签的位置继续读。

具体实现有两种主流方式：

基于ObjectId（_id）的分页

MongoDB的每个文档都有一个唯一的 _id 字段，默认是ObjectId类型，它本身带有时间戳信息，基本上是递增的,这是最简单高效的方案。

第一页查询：
```
db.collection.find({}).sort({_id: 1}).limit(10)
```
返回10条数据，同时记住最后一条数据的 _id，比如是 last_id。
第二页及后续页查询：
```
db.collection.find({_id: {$gt: last_id}}).sort({_id: 1}).limit(10)
```
这个查询的意思是：查找所有 _id 大于 last_id 的记录，按 _id 排序,取前10条。

为什么快？ 因为 _id 字段上默认就有唯一索引，$gt 查询可以利用这个索引进行非常快速的定位，直接“seek”到开始位置，完全避免了笨重的 skip 操作，无论你要查第10页还是第10000页,速度都几乎一样快。

基于其他字段的分页（如创建时间）

如果你的排序需求不是按 _id，而是按其他字段，比如文章的发布时间 create_time。

第一页查询：
```
db.collection.find({}).sort({create_time: -1, _id: -1}).limit(10)
```
注意，这里在按 create_time 降序排序的同时，加上了按 _id 降序排序，这是因为 create_time 很可能不是唯一的，多篇文章可能在同一秒发布，加上唯一的 _id 可以确保排序的确定性,避免分页时出现重复或遗漏。
第二页及后续页查询： 假设上一页最后一条记录的 create_time 是 last_time，_id 是 last_id。
```
db.collection.find({
  $or: [
    {create_time: {$lt: last_time}},
    {create_time: last_time, _id: {$lt: last_id}}
  ]
}).sort({create_time: -1, _id: -1}).limit(10)
```
这个查询条件稍微复杂一点,但逻辑很清晰：
1. 首先找所有 create_time 小于 last_time 的记录（对于降序来说，这就是更早的数据）。
2. create_time 相等，再找那些 _id 小于 last_id 的记录。
这样就能精准地定位到下一页的起始点，为了实现高性能，你必须在 create_time 和 _id 上建立复合索引：db.collection.createIndex({create_time: -1, _id: -1})。

第三部分：应对特殊场景和优化技巧

如何跳转到特定页码？ 基于游标的分页虽然快，但它本质上是“下一页/上一页”的模式，无法直接跳转到第N页，如果业务上确实需要这个功能，可以做一个权衡：对于靠前的页码（比如前100页），可以谨慎地使用 skip，因为跳过几百几千条数据开销尚可接受，对于更深的页码，最好引导用户使用搜索、筛选功能来缩小数据集,而不是盲目地翻页。
“上一页”怎么实现？ 实现“上一页”的逻辑和“下一页”对称，以按 _id 排序为例，当你翻到第二页时，不仅要记住最后一条的 _id (last_id)，还要记住第一条的 _id (first_id)，点击“上一页”时，查询条件就是 {_id: {$lt: first_id}} 然后排序用 sort({_id: -1}).limit(10)，这样就能拿到上一页的10条数据（取回来后再反转一下顺序显示，或者前端直接处理）。
计数总数 count() 的陷阱 在分页时，前端经常要求显示总页数，直接使用 db.collection.countDocuments() 在全量数据上是非常慢的，因为它可能要执行全表扫描，如果数据量巨大，这个操作应该避免或异步执行，一个更好的办法是，如果数据增长不特别频繁，可以用一个单独的计数器来维护总数，或者直接不显示精确的总数，只显示“查看更多”按钮。