MongoDB分页优化：利用索引排序与游标定位

先看一个核心结论：skip() + limit() 在大数据量下越来越慢，根源在于 skip(N) 并非直接跳到第 N 条，而是让 MongoDB 老老实实扫描、加载并丢弃前 N 条匹配文档。N 越大，CPU 和内存开销越惊人——尤其当 sort() 没走索引时，还要先做内存排序，再叠加跳过，性能直接呈 O(N) 下滑。

为什么 skip() + limit() 在大数据量下会越来越慢

因为 skip(N) 的真正逻辑是：先扫描前 N 条，然后扔掉它们。这个过程中，CPU 和内存一直在忙活，N 越大，开销自然越线性增长。更麻烦的是，如果配合了 sort()，而排序字段又没有走索引，MongoDB 会先做内存排序，再把排序后的结果丢给 skip——这相当于在 O(N log N) 的基础上再压上 O(N) 的负重，性能不崩才怪。

实际中常见的报警信号有哪些？

• 第 100 页的响应时间比第 1 页慢 5 倍以上，甚至直接超时
• 同一个分页请求，前后两次返回的结果顺序不一致（尤其在高写入量的集合里）
• explain("executionStats") 显示 nReturned 也许只有几十条，但 totalDocsExamined 却飙到几十万——所有时间都花在了扫描那些“将被丢弃”的文档上

必须加索引：否则 sort() + skip() 就是定时冲击波

MongoDB 处理 sort() + skip() + limit() 的顺序是固定的：先排序 → 再跳过 → 最后取数。如果排序字段不能通过索引完成，就会触发 inMemorySort，而内存排序根本无法提前跳过中间数据——这意味着你每跳一页，数据库都得把整个有序结果集走一遍。排序字段没索引的情况下，skip 的成本简直是爆炸式的。

正确的做法是让排序字段的组合索引同时覆盖查询条件和排序需求：

• 单字段排序（比如 createdAt），建单字段索引：db.collection.createIndex({ createdAt: -1 })
• 多字段排序（例如 { status: 1, createdAt: -1 }），索引字段顺序必须与排序完全一致，并且尽量包含查询中用到的等值字段（比如 status: "active"）
• 关键细节：排序中务必加入 _id 字段去重，例如 .sort({ status: 1, createdAt: -1, _id: 1 })——否则排序字段值重复时，分页会错位，来回翻页数据不一致

用游标替代 skip()：基于上一页末尾值构造查询条件

游标分页的思路很简单：记住上一页最后一条文档的位置，而不是“跳过多少条”。它把上一页最后一条文档的关键排序字段值（比如 createdAt 和 _id）作为下一页的查询起点，彻底绕过了 skip 那套“扫描再扔掉”的笨办法。

举个例子（按 createdAt 降序分页）：

db.collection.find({  
  $or: [
    { createdAt: { $lt: ISODate("2024-01-01T10:00:00Z") } },
    { createdAt: ISODate("2024-01-01T10:00:00Z"), _id: { $lt: ObjectId("...") } }
  ]
}).sort({ createdAt: -1, _id: -1 }).limit(10)

这里有几个要点：

• 不能只依赖 createdAt，必须联合 _id 来处理时间完全相同的数据——否则数据边界会模糊，分页结果不稳定
• 前端需要传回上一页最后一条的 createdAt 和 _id，而不是页码号
• 首次查询仍然需要完整排序 + limit，但后续所有翻页都是范围查询，性能稳定在 O(log n) 级别，跟翻到第几页无关

实际部署时最容易被忽略的点

游标分页听起来很美好，但并不是“加上就快”——它依赖几个隐性前提，稍不注意就翻车：

• 排序字段必须单调递增/递减且写入稳定。比如官方推荐的 createdAt 就比用户自填的 updatedAt 可靠得多——后者可能被用户随意修改，破坏单调性
• 索引必须存在且被查询命中。不要想当然，一定要用 explain() 确认 executionStats.executionStages.stage === "IXSCAN"，否则又是内存排序的老路
• 业务要接受“不可跳页”：用户不能直接输入页码跳到第 500 页，只能逐页或前后翻。这是用功能灵活性换性能，必须提前沟通好
• 如果用开源库（比如 mongodb-cursor-pagination），注意它默认会编码游标值，但解码失败时不会报错，而是静默返回空结果——所以一定要在校验环节对游标参数做合法性检查，别让用户随便传个乱码就崩溃了