skip()在分片集群中变慢是因为各shard均需执行skip(n)+limit(m)再合并，n越大扫描越多、传输与内存压力越大；应改用sort+游标分页，以最后一条的createdat和_id为下一页起点，并确保索引与分片键设计匹配。
为什么 skip() 在分片集群里会越来越慢
MongoDB 分片环境下，skip() 不是“跳过前 N 条再取”，而是每个 shard 都要各自执行 skip(N) + limit(M)，再把结果汇总到 mongos 做二次合并。N 越大，每个 shard 处理的数据量就越多，网络传输和内存压力也越大——尤其当某 shard 实际只存了少量匹配文档时，它仍要扫描大量无关数据来凑够 skip() 数。
常见错误现象：db.collection.find().skip(100000).limit(20) 在单机可能毫秒级，在 3-shard 集群里可能卡住 2s+，且随着页码增大线性退化。
- 分片键与查询条件不匹配时，
skip()无法下推，所有 shard 全表扫 - mongos 的聚合内存限制（
allowDiskUse: false默认）容易触发Exceeded memory limit for $group - 游标超时（
maxTimeMS）在高 skip 下极易触发，返回Cursor not found
用 sort + _id 游标替代 skip 的实操要点
连续分页必须放弃页码思维，改用“上一页最后一条的排序字段值”作为下一页起点。最稳妥的是组合 sort({ createdAt: -1, _id: -1 }) ——_id 是 ObjectId，天然唯一、单调递增，能彻底避免时间戳重复导致的漏/重数据。
使用场景：后台列表、消息流、日志查看等需要稳定向前/向后翻页的接口。
- 首次请求：用
find({}).sort({ createdAt: -1, _id: -1 }).limit(20)，拿到第 20 条的{ createdAt, _id } - 下一页：用
find({ $or: [ { createdAt: { $lt: last.createdAt } }, { createdAt: last.createdAt, _id: { $lt: last._id } } ] }).sort({ createdAt: -1, _id: -1 }).limit(20) - 注意：
createdAt字段必须有索引，且索引顺序需与 sort 一致（{ createdAt: -1, _id: -1 }）
分片键设计如何影响游标分页效率
如果分片键是 { userId: 1 }，而你的分页查询是全站按时间排序（sort({ createdAt: -1 })），那无论用 skip 还是游标，mongos 都得从所有 shard 拉数据再合并——根本绕不开广播查询。这时候游标只是“不更差”，不是“变快”。
真正能提速的，是让分片键参与分页过滤：
- 用户个人数据页：查询带
{ userId: "u123" }，分片键可路由到单 shard，游标直接生效 - 全局热榜页：若必须跨 shard，优先选
{ createdAt: -1, _id: -1 }为分片键（仅限写入均匀、无热点场景） - 避免用
{ _id: "hashed" }当分片键——它打散数据但破坏了排序局部性，游标无法利用索引范围扫描
游标参数传递与客户端兼容性陷阱
游标值不能直接传 ObjectId("...") 字符串给前端，得序列化成安全字符串；后端解析时也得严格校验格式，否则 new ObjectId(invalid) 会静默转成全零 ID，查出错乱数据。
常见错误现象：前端传错格式（如多加空格、大小写混用），后端没校验，结果返回首条或空数组。
- 推荐做法：用
last._id.toString()生成游标 token，后端用ObjectId.isValid(str) && new ObjectId(str)双重校验 - 不要把
createdAt直接当字符串传——时区、精度（毫秒 vs 秒）、浮点误差都可能引发边界错位 - 游标失效场景：用户长时间停留后翻页，原数据已被删除或更新，应捕获
no matching document并降级为首页重载
游标不是银弹。它解决的是“连续翻页”的稳定性，但无法绕过分片架构对全局排序查询的物理限制——真要高频查全量热榜，得考虑预聚合或单独建宽表。
