基于Mongoid实现多字段条件排序及百万级文档分页查询

针对百万级文档的多字段排序+分页需求，核心是利用复合索引优化性能，同时避开深分页的坑，下面给你详细拆解实现方案：

从你的示例文档推测，你大概率希望排序优先级是：在线用户优先（online降序）→ 点赞数高的优先（like降序）→ 分数高的优先（score降序）。

为了让MongoDB高效完成排序，必须创建匹配排序顺序的复合索引——否则百万级数据会触发全表扫描+内存排序，性能直接崩盘：

db.users.createIndex({ online: -1, like: -1, score: -1 })

划重点：索引的字段顺序、升降序必须和你sort()的参数完全对应！MongoDB的复合索引是前缀匹配的，顺序错了就用不上索引。

分页分两种场景，对应不同的实现方式：

1. 浅分页（前几页）：用skip()+limit() #

如果只是取前几页数据，这种方法足够简单直接：

// 第一页，每页10条
db.users.find()
  .sort({ online: -1, like: -1, score: -1 })
  .limit(10)

// 第二页
db.users.find()
  .sort({ online: -1, like: -1, score: -1 })
  .skip(10)
  .limit(10)

但绝对不要用这种方法做深分页（比如skip(100000)），因为MongoDB需要扫描前面所有跳过的文档，百万级数据下速度会慢到无法接受。

2. 深分页（推荐）：基于最后一条文档的游标分页 #

这种方法的核心是记住上一页最后一条文档的排序字段值，用这些值作为查询条件直接定位下一页，完全利用索引，性能不受页码影响：

步骤1：获取第一页数据 #

// 多取1条用来判断是否有下一页
const page1 = db.users.find()
  .sort({ online: -1, like: -1, score: -1, _id: -1 }) // 加上_id，避免相同排序字段的文档顺序混乱
  .limit(11)
  .toArray()

// 处理分页结果
const hasNextPage = page1.length > 10
const currentPageData = page1.slice(0, 10)
// 记录上一页最后一条文档的关键值
const lastDoc = currentPageData[currentPageData.length - 1]
const lastOnline = lastDoc.online
const lastLike = lastDoc.like
const lastScore = lastDoc.score
const lastId = lastDoc._id

步骤2：获取下一页数据 #

用$or组合条件，精准定位到上一页之后的文档：

const page2 = db.users.find({
  $or: [
    { online: { $lt: lastOnline } }, // 在线状态比上一页最后一条低
    { online: lastOnline, like: { $lt: lastLike } }, // 在线状态相同，点赞数更低
    { online: lastOnline, like: lastLike, score: { $lt: lastScore } }, // 前两个字段相同，分数更低
    { online: lastOnline, like: lastLike, score: lastScore, _id: { $lt: lastId } } // 前三个字段都相同，用_id唯一区分
  ]
})
.sort({ online: -1, like: -1, score: -1, _id: -1 })
.limit(11)
.toArray()

为什么要加_id？因为可能存在多个文档的online、like、score完全相同，用_id（唯一值）作为最后排序字段，能保证排序的绝对唯一性，避免分页时漏掉或重复文档。

用explain()查看索引是否被正确使用：

db.users.find()
  .sort({ online: -1, like: -1, score: -1 })
  .limit(10)
  .explain("executionStats")

看executionStats.totalDocsExamined是否等于executionStats.nReturned，如果相等，说明索引被高效利用了；如果前者远大于后者，那说明索引没建好，得检查索引顺序和排序顺序是否匹配。

• 如果你的查询还有额外过滤条件（比如筛选特定name），要把等值过滤条件放在复合索引的最前面，比如{ name: 1, online: -1, like: -1, score: -1 }，这样MongoDB能先过滤再排序，性能更好。
• 内存排序默认有100MB的限制，百万级数据如果不用索引，肯定会触发磁盘排序，速度极慢，所以索引是必须的。

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