先看一个核心结论：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），注意它默认会编码游标值，但解码失败时不会报错，而是静默返回空结果——所以一定要在校验环节对游标参数做合法性检查，别让用户随便传个乱码就崩溃了
