MongoDB的聚合管道提供了强大的数据处理能力，其中$skip和$limit阶段常被用于实现分页功能。然而，简单的分页操作在数据量激增时会暴露出严重的性能问题，需要结合具体的业务场景进行深度优化。
聚合管道中skip与limit的基础用法
在MongoDB的聚合框架中，$skip和$limit是两个非常基础且重要的管道操作符。$limit用于限制管道传递给下一个阶段的文档数量，而$skip则用于跳过指定数量的文档。将它们结合使用，可以轻松实现传统的分页逻辑。例如，每页显示10条数据，要获取第3页的数据，我们需要先跳过前20条，然后限制输出10条。
在编写聚合管道时，操作符的顺序至关重要。如果先使用$limit再使用$skip，结果将完全不同。为了正确实现分页，必须先执行$skip跳过前面不需要的文档，然后再执行$limit截取当前页的数据。下面是一个标准的聚合管道分页代码示例。
// 获取第3页的数据，每页10条
db.collection.aggregate([
// 第一步：匹配业务条件，尽早过滤文档
{ $match: { status: "active" } },
// 第二步：按创建时间降序排序
{ $sort: { create_time: -1 } },
// 第三步：跳过前20条文档
{ $skip: 20 },
// 第四步：限制只返回10条文档
{ $limit: 10 }
])
这种写法在逻辑上非常直观，易于理解。当数据集较小时，它能够快速返回结果。但需要注意的是，MongoDB在处理管道时，$skip和$limit的位置会影响优化器的行为。如果能在$skip之前尽可能多地过滤掉不需要的文档，可以有效减少后续阶段的处理压力。
深度分页的性能陷阱与原因分析
虽然上述基础用法在数据量较小的情况下表现良好，但当集合中的文档数量达到百万甚至千万级别时，这种分页方式会导致严重的性能下降。核心原因在于$skip操作符的工作机制。MongoDB在执行$skip时，并不能真正在物理层面直接定位到指定的偏移量，而是必须从索引或集合的起始位置开始，扫描并处理前面所有的文档，直到达到跳过的数量。
这意味着，如果用户请求第1000页的数据，每页20条，MongoDB需要扫描并跳过前19980条文档，然后才能获取所需的20条记录。随着页码的增加，扫描的文档数量线性增长，导致CPU和内存资源被大量消耗，响应时间急剧上升。此外，如果查询条件无法有效利用索引，数据库甚至需要进行全表扫描，这将是灾难性的。
通过分析explain()的执行计划，我们可以清晰地看到totalDocsExamined字段的数值远大于实际返回的文档数。这种无效的数据扫描不仅拖慢了当前查询，还会占用数据库服务器的资源，影响其他并发请求的处理。因此，在架构设计阶段，必须将深度分页视为一个潜在的性能瓶颈并加以规避，避免在生产环境出现慢查询告警。
优化方案：基于唯一键的游标分页
为了解决深度分页的性能问题，业界通常采用基于唯一键的游标分页方案。这种方案放弃了传统的页码概念，转而使用上一页最后一条记录的唯一标识（如_id或时间戳）作为游标。下一页的查询不再是跳过指定数量的文档，而是直接通过范围查询（$gt）获取游标之后的数据。
在聚合管道中，我们可以利用$match阶段来实现这种范围查询。假设我们按照_id字段进行升序排序，每次查询时记录最后一条数据的_id值。下一次查询时，将该_id值作为条件传入$match中，只查询大于该值的记录。这样，无论查询到第几页，数据库始终只需要扫描并返回当前页所需的数据量，彻底消除了$skip带来的扫描开销。
// 游标分页：获取上一页最后一条记录 _id 之后的10条数据
var lastId = ObjectId("上一页最后一条记录的_id");
db.collection.aggregate([
// 第一步：匹配业务条件，并附加范围查询
{ $match: {
status: "active",
_id: { $gt: lastId }
} },
// 第二步：按 _id 升序排序
{ $sort: { _id: 1 } },
// 第三步：限制只返回10条文档
{ $limit: 10 }
])
这种游标分页方案的优势在于其查询性能极其稳定，不受页码深度的影响。只要游标字段建立了索引，每次查询的时间复杂度都是常数级别的。不过，它也有一些局限性，比如无法直接跳转到指定页码，只能提供上一页和下一页的功能。对于大多数前端无限滚动列表或加载更多场景来说，游标分页是最佳选择。如果业务强需求必须支持跳页，可以考虑限制最大可跳转的页码，或者采用混合模式，浅分页使用$skip与$limit，深分页则强制转换为游标分页。