## 01、痛点

上周三夜里，我们一个用户 Feed 接口突然告警，P99 从 40ms 涨到 3.2s。我是老李，负责这块后端。第一反应是查 MongoDB 慢日志，看到一条语句：

```
db.feeds.find({ userId: 'u_1001' }).sort({ createdAt: -1, _id: -1 }).skip(200000).limit(20)
```

这条语句来自运营后台，用户点到了第 1000 页。我们原本以为换了 MongoDB 就不会再遇到 MySQL 那种 LIMIT 100000,20 的深分页，结果还是被打脸。更麻烦的是，这个接口不是低频后台，而是 C 端 Feed 的旧实现，一直沿用 page、size 和 total。数据量从 5 万涨到 200 万后，深页查询把连接池占满，CPU 飙到 90%。

深分页的成本在哪儿？MongoDB 的 skip 并不是直接跳到第 200001 条位置，而是按排序顺序把前面 200000 条索引项扫描并丢弃，然后再返回 20 条。第 1 页只检查 20 条，第 1000 页却要检查 200020 条。问题不在 SQL 还是 NoSQL，而在“跳过大量偏移量”这个访问模式。这就是今天要聊的话题：为什么 MongoDB 不会自动消灭深分页，以及怎么用 lastId + createdAt 游标翻页解决 C 端顺序消费场景。

## 02、是什么

先分清两个概念：偏移分页和游标分页。偏移分页就是常见的 skip/limit 或 SQL 的 OFFSET/LIMIT。它明确知道总页数，可以跳页，但成本随 offset 增大而上升。游标分页也叫 Seek Pagination 或 keyset pagination，它不传页码，只传上一页最后一条记录的游标，然后查询比游标更旧的数据。

MongoDB 中游标分页依赖两个关键点：排序稳定性和索引顺序。排序稳定性是指，如果只按 createdAt 降序排序，当很多记录 createdAt 相同时，MongoDB 不保证这些记录的顺序每次查询一致，翻页就可能重复或漏掉。解决方法是加一个唯一字段做决胜条件。这里我们选 _id，因为 _id 天然唯一且不可变。排序写成：

```
{ createdAt: -1, _id: -1 }
```

游标就需要同时记录上一条的 createdAt 和 _id。下一页查询条件分两段：要么 createdAt 更早，要么 createdAt 相等但 _id 更小。用 $or 表达：

```
{
  $or: [
    { createdAt: { $lt: new Date(lastCreatedAt) } },
    { createdAt: new Date(lastCreatedAt), _id: { $lt: ObjectId(lastId) } }
  ]
}
```

这样查询可以走 { createdAt: -1, _id: -1 } 或 { userId: 1, createdAt: -1, _id: -1 } 的范围索引，从游标位置继续向后取一页，而不是从第 0 条开始跳过。

所以，Seek Pagination 的本质是把“按数量跳过”变成“按值定位”。索引擅长按值定位，不擅长按偏移计数。

## 03、为什么

为什么 MongoDB 不会自动消灭深分页？因为 skip 的语义没有变。即使底层是 WiredTiger 的 B 树索引，也没有办法直接定位到“第 200001 个”位置。偏移量不是索引键，索引只能高效定位到某个值或值范围，不能高效跳到某个编号。skip 200000 时，引擎必须从排序起点开始，逐个索引项扫描并丢弃 20 万条，再把后面的 20 条返回。

如果排序字段和查询条件没有完全命中索引，情况更糟。MongoDB 还可能把大量文档读入内存排序，超过 100MB 直接报错。即使命中索引，深页的 totalKeysExamined 和 totalDocsExamined 依旧会膨胀，执行时间随页数线性增长。

在分片集群里，这种成本会被进一步放大。mongos 需要从各个分片拉取符合排序条件的数据，合并排序后再执行 skip。深页意味着每个分片都可能返回巨量数据，网络传输、内存排序、临时空间都会增加。换句话说，分布式不仅没有自动优化深分页，很多时候还会放大它。

SQL 的 OFFSET 也一样。很多团队把 MySQL 换成 MongoDB，代码只是把 LIMIT 100000,20 改成 skip(100000).limit(20)。数据库变了，访问模式没变，深分页自然不会消失。所以问题根源是访问模式：随机跳页天然昂贵，顺序消费天然可优化。

## 04、架构

既然根因在访问模式，方案就要按访问模式拆开。我的建议是：后台管理保留 Pageable，用户 Feed 改 Cursor Pagination。

后台管理为什么保留 Pageable？因为运营、客服、风控确实需要知道总页数，也需要跳到某一页。后台使用频率低，数据规模通常可控，保留页码分页可以接受，但要限制每页最大条数，比如 20/50，并且最好限制最大深度或提供筛选、搜索、时间范围，避免人工点到第 1000 页。

用户 Feed 则完全不同。C 端用户几乎不会点击页码跳页，他们的行为是向下滚动，不断加载更多。这种顺序消费场景天然适合游标分页。接口不再出现 page、size、total，而是：

```
{
  'items': [...],
  'nextCursor': 'MTY...',
  'hasMore': true
}
```

nextCursor 由最后一条记录的 createdAt 与 _id 编码而来，base64 之外还可以加一层签名，避免客户端伪造。服务端解析后生成 $or 条件，继续走范围查询。

索引设计上，Feed 集合典型查询是某个用户的时间线，复合索引可以设计为：

```
{ userId: 1, createdAt: -1, _id: -1 }
```

等值字段 userId 放最前，排序字段 createdAt、_id 按查询排序顺序放后面。这样每个用户的时间线范围查询都能走索引，游标越深，性能和第一页仍然是一个量级。

架构上可以这样落地：网关层定义两套分页协议。后台管理传 page 和 size，Feed 传 cursor 和 limit。后台服务继续用 Pageable。Feed 服务只接受 CursorRequest，如果发现客户端传 skip 或 page，直接返回参数错误，从协议上杜绝深分页。

## 05、实战

先造一批数据。假设有一个 feed 集合，用下面的 Mongo shell 脚本插入 20 万条：

```
for (let i = 0; i < 200000; i++) {
  db.feeds.insertOne({
    userId: 'u_1001',
    createdAt: new Date(Date.now() - i * 1000),
    content: 'feed_' + i
  });
}
db.feeds.createIndex({ userId: 1, createdAt: -1, _id: -1 });
```

先看第 1 页：

```
db.feeds.find({ userId: 'u_1001' }).sort({ createdAt: -1, _id: -1 }).skip(0).limit(20).explain('executionStats');
```

可以看到 totalKeysExamined 大约是 20，totalDocsExamined 也是 20，执行时间在毫秒级。

再看深页：

```
db.feeds.find({ userId: 'u_1001' }).sort({ createdAt: -1, _id: -1 }).skip(200000).limit(20).explain('executionStats');
```

我们压测环境里，totalKeysExamined 变成 200020，totalDocsExamined 也变成 200020，执行时间从 4ms 升到 680ms 左右。数据量再大，这个数字还会继续恶化。这说明 skip 的代价不是返回的 20 条，而是被丢弃的 20 万条。

接下来实现 lastId + createdAt 游标翻页。下面是 Node.js 的示例，核心逻辑只有几行：

```
async function getFeed(userId, cursor, limit = 20) {
  const sort = { createdAt: -1, _id: -1 };
  const query = { userId };

  if (cursor) {
    const { lastId, lastCreatedAt } = decodeCursor(cursor);
    query.$or = [
      { createdAt: { $lt: new Date(lastCreatedAt) } },
      { createdAt: new Date(lastCreatedAt), _id: { $lt: ObjectId(lastId) } }
    ];
  }

  const items = await db.feeds.find(query).sort(sort).limit(limit + 1).toArray();
  const hasMore = items.length > limit;
  const resultItems = hasMore ? items.slice(0, limit) : items;
  const nextCursor = hasMore ? encodeCursor(resultItems[resultItems.length - 1]) : null;

  return { items: resultItems, nextCursor, hasMore };
}
```

这里多取一条 limit + 1，只是为了判断 hasMore，不会额外返回给客户端。encodeCursor 可以把最后一条的 createdAt 和 _id 编码成字符串；decodeCursor 则负责解析并校验 ObjectId 是否合法。

用游标翻页连续请求 100 页，延迟基本和第一页一致。因为每一页都从索引的某个值开始，范围扫描只检查 21 条左右。再 explain 一次，totalKeysExamined 大约是 21，而不是 200021。

有两个坑要提醒。第一，createdAt 可能重复，所以必须带 _id 做决胜条件，否则相同时间的数据可能在翻页时被漏掉或重复。第二，游标字段必须是不可变字段。如果业务会修改 createdAt，就不要用 createdAt 做游标，改用 _id 或一个不可变的时间字段。

## 06、洞见

这次踩坑给我最大的启发是：分页问题来自访问模式，而不是来自 SQL 还是 NoSQL。很多团队迁移到 MongoDB，只是把 OFFSET 换成 skip，分页交互还是“第几页/共几页”。只要用户仍然能跳到第 1000 页，深分页成本就不会消失。

数据库能帮你做的是优化某种访问模式，而不是消除访问模式本身。MongoDB 的索引可以快速定位到某个值或范围，但无法高效定位到第 N 条。键集分页利用前者，偏移分页掉进后者。

这也能解释为什么后台可以继续用 Pageable。不是后台不会遇到深分页，而是后台访问频率低、用户量少，限制深度后成本可以接受。真正高频的 C 端 Feed，必须改造成顺序消费。

如果产品坚持要总页数，我建议先让产品回答一个问题：用户真的需要跳到第 1000 页吗？大多数情况下，他们要的是搜索、筛选、时间范围。优化分页，有时不是改 SQL 或 MongoDB，而是改产品交互。

所以最后我们定了两条原则：能顺序消费就不要随机跳页；需要跳页就限制深度。后台管理保留 Pageable，用户 Feed 改 Cursor Pagination。

## 07、行动

落地时，我建议按下面步骤推进。

第一，盘点所有 MongoDB 分页接口，找出 skip 超过一定阈值的查询。慢日志里通常能看到 totalKeysExamined 很大的语句。

第二，按场景分类。后台管理保留 Pageable，但设置每页最大条数不超过 50，并限制允许翻到的最大深度，或引导使用搜索和筛选。C 端 Feed 改造成 Cursor Pagination，不再暴露 page、size、total。

第三，建索引。确保索引顺序和查询排序一致。典型像 { userId: 1, createdAt: -1, _id: -1 }。用 explain('executionStats') 验证 totalKeysExamined 是否接近每页条数。

第四，接口改造。Feed 接口返回 nextCursor 和 hasMore，前端改为滚动加载。旧接口可以保留一段时间做灰度，新版本先发前端兼容，稳定后再下线 skip 实现。

第五，测试。用相同数据量对比 skip 深页和游标翻页的延迟与扫描数。形成回归用例，保证以后不会有人在 Feed 接口里加回 page 参数。

第六，监控。观察慢查询、游标接口的 P99、索引命中率。还可以设置告警，当某条查询 totalKeysExamined 超过阈值时通知。

决策表如下：

| 场景 | 分页方式 | 是否返回 total | 是否可跳页 | 深度限制 |
| 后台管理 | Pageable | 是 | 是 | 限制每页条数和最大深度 |
| 用户 Feed | Cursor | 否 | 否 | 顺序加载 |
| 内部导出 | 流式游标 | 否 | 否 | 顺序扫描 |

## 08、小结

MongoDB 的 skip/limit 用起来简单，但深分页成本会随偏移量线性增长。换 NoSQL 不会自动消灭深分页，因为真正的根因是访问模式：随机跳页与顺序消费的成本结构不同。

解决思路不是一刀切，而是按场景拆开。后台管理保留 Pageable，限制深度；用户 Feed 改用 lastId + createdAt 游标翻页，配合 { userId: 1, createdAt: -1, _id: -1 } 这样的索引，让每页查询只扫描固定条数，不再越翻越慢。

数据库不会替你决定访问模式。先把交互和接口协议管住，才是解决深分页的第一步。

## 09、链接与概念说明

概念说明：

- 深分页：跳过大量偏移量后才返回结果的分页方式，成本与偏移量正相关。
- 游标翻页：用上一页最后记录的排序字段值作为起点继续查询，也叫 Seek Pagination 或 keyset pagination。
- 排序稳定性：排序字段相等时，用唯一字段 _id 做决胜条件，避免翻页重复或遗漏。
- 索引顺序：查询的排序字段和顺序需要与复合索引匹配，否则可能出现内存排序。
- ESR 原则：复合索引优先放置等值字段，再放排序字段，最后放范围字段。

建议阅读 MongoDB 官方文档：

- Cursor.skip：docs.mongodb.com/manual/reference/method/cursor.skip/
- Cursor.sort：docs.mongodb.com/manual/reference/method/cursor.sort/
- Explain Results：docs.mongodb.com/manual/reference/explain-results/
- ObjectId：docs.mongodb.com/manual/reference/method/ObjectId/
- Compound Indexes：docs.mongodb.com/manual/core/index-compound/

上周三夜里，我们一个用户 Feed 接口突然告警，P99 从 40ms 涨到 3.2s。我是老李，负责这块后端。第一反应是查 MongoDB 慢日志，看到一条语句：

《Spring Mongo实战》第12招 深分页也会慢

数据量一上来，MongoDB 的 skip/limit 也会越来越慢。本文结合第1页与深页对比，讲清排序稳定性与索引顺序，用 lastId+createdAt

架构师

数据库

后端

架构设计

MongoDB深分页性能问题源于skip偏移扫描，非SQL或NoSQL差异。解决方案按场景拆分：后台管理保留Pageable并限制深度，用户Feed改用lastId+createdAt游标翻页，配合{userId:1,createdAt:-1,_id:-1}索引，确保每页查询只扫描固定条数，避免越翻越慢。

代码解释

MongoDB

MySQL

NoSQL

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Spring Mongo实战》第12招 深分页也会慢-腾讯云开发者社区-腾讯云

《Spring Mongo实战》第12招深分页也会慢

《Spring Mongo实战》第12招深分页也会慢

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring Mongo实战》第12招 深分页也会慢

《Spring Mongo实战》第12招 深分页也会慢

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring Mongo实战》第12招深分页也会慢

《Spring Mongo实战》第12招深分页也会慢