MongoDB非ObjectId类型_id实现无skip高效分页方案咨询

直接针对核心疑问给出明确结论：

1. 建了索引的GUID类型_id完全具备可利用的排序规则：MongoDB的B树索引默认按照字段值的二进制比较顺序构建键的排序，不管_id存的是递增的ObjectId、随机生成的GUID还是其他类型值，只要字段上存在索引，索引层面的排序逻辑、范围匹配逻辑都是完全生效的，不存在因为值是随机生成就无法排序、无法做范围匹配的问题。
2. 必须在每次分页查询时显式指定_id字段的排序规则：MongoDB在查询不指定sort参数时，返回结果的顺序由文档磁盘存储位置、索引命中路径等因素决定，属于不确定顺序，尤其在WiredTiger存储引擎下，文档移动、删除空间复用等操作都会打乱自然返回顺序，不指定固定排序的分页一定会出现重复拉取、漏拉数据的问题。
3. 基于GUID类型_id的游标分页实现逻辑和ObjectId版本完全一致，性能远优于skip+limit方案，不会因为_id是随机GUID出现性能衰减。

具体实现方式 #

全程保持统一的排序规则（建议固定为_id升序，全链路不要改动），按以下步骤实现：

• 第一页查询：不需要传入分页参数，直接叠加业务过滤条件、固定排序、页大小限制即可，查询示例：

// 拉取第一页，页大小为10
db.collection_name.find({
  // 这里写你的业务过滤条件，所有分页请求的过滤条件必须完全一致
})
.sort({ _id: 1 }) // 固定按_id升序，必须显式声明
.limit(10)

• 游标传递：第一页结果返回给客户端时，额外附带当前页最后一条文档的_id值作为下一页的分页游标，不需要传递skip值。
• 后续页查询：客户端请求下一页时，把上一页拿到的最后一条_id值传回服务端，服务端叠加_id的范围条件，保持和之前完全一致的排序、limit规则即可，查询示例：

// 拉取后续页，lastId为上一页返回的最后一条文档的GUID类型_id
db.collection_name.find({
  // 和之前完全一致的业务过滤条件
  _id: { $gt: lastId } // 因为是升序，所以取比lastId大的后续文档
})
.sort({ _id: 1 }) // 排序规则和第一页完全一致，不能修改
.limit(10)

注意事项 #

• 随机GUID作为_id唯一的影响是写入时B树索引会产生更多节点分裂，写入性能略低于递增的ObjectId，但读分页的性能和ObjectId方案没有差异：查询时会直接从索引中lastId对应的位置开始连续读取指定数量的索引项，不需要遍历跳过前面的文档，性能比skip+limit高2~3个数量级，数据量越大优势越明显。
• 排序规则和范围条件必须严格对应：如果选择_id: -1降序排序，对应的范围条件要改成_id: { $lt: lastId }，排序规则一旦在链路中变更，就会出现分页错乱。
• 如果需要按业务字段（比如创建时间、热度值）排序，不要单独用_id作为游标，要把排序字段和_id组成联合排序键，例如按创建时间倒序分页时，排序规则写为.sort({ createTime: -1, _id: 1 })，对应的范围条件也要同时匹配两个字段的比较逻辑，避免排序字段值重复时出现漏数。

内容的提问来源于stack exchange，提问作者user17365408