排行榜不必预排序，但高频实时聚合代价高；推荐用冗余rank_score字段+复合索引（status, rank_score, _id）实现毫秒级查询，并通过增量更新+缓存兜底处理多维聚合。
排行榜必须预排序？不一定，但实时聚合代价很高
直接结论：对高频访问的排行榜（如“今日TOP100”），$sort + limit 在聚合管道里用一次不致命，但若每秒被调用数百次、且集合文档超百万，就会触发内存溢出或慢查询——因为 $sort 是阻塞阶段，必须把所有匹配文档拉进内存再排。
真正的问题不在“能不能用”，而在“要不要每次都算”。比如用户刷一次榜单就执行 db.users.aggregate([{$match: {status: "active"}}, {$sort: {score: -1}}, {$limit: 100}])，看似简洁，实则每次都在重复做全量排序。
- 真实场景中，95% 的排行榜读多写少（分数更新远少于展示）
-
$sort对字段类型敏感：如果score混合了NumberInt、NumberLong甚至字符串，排序结果可能错乱（MongoDB 不做隐式类型转换） - 没有索引时，
$sort会强制 collection scan，explain 显示"stage": "COLLSCAN"就是警报
最简可靠的预排序方案：带分数的冗余字段 + 复合索引
与其在查询时拼 $sort，不如把排序依据固化到文档结构里。典型做法是在用户文档中加一个 rank_score 字段（数值型），写入时就按业务规则算好，例如：
db.users.updateOne(
{_id: ObjectId("...")},
{$set: {score: 872, rank_score: 872}}
)
然后建复合索引支撑快速取榜：
-
db.users.createIndex({status: 1, rank_score: -1, _id: 1})—— 符合 ESR 原则（等值过滤 → 排序字段 → 唯一字段保顺序稳定） - 查榜时直接
db.users.find({status: "active"}).sort({rank_score: -1}).limit(100)，走索引，毫秒级 - 避免只对
rank_score单独建索引：万一多人同分，MongoDB 不保证返回顺序，加上_id才能稳序
分数聚合 ≠ 实时重算，而是增量更新 + 缓存兜底
当排行榜依赖多维度聚合（比如“按部门统计最高分”），$group + $max 看似合理，但别让它出现在主请求链路里。真实系统里，这类聚合应拆成两步：
- 写时触发：用户提交新成绩后，用
updateOne直接更新对应部门的缓存文档（如dept_leaderboard集合），字段如{dept: "tech", top_score: 942, user_id: "...", updated_at: ISODate(...)} - 读时直取：
db.dept_leaderboard.find({dept: "tech"})，无排序、无聚合、无压力 - 定时校验：每天凌晨跑一次全量
aggregate校准缓存，发现偏差超过阈值才告警
强行在 API 里嵌套 db.users.aggregate([{$match: {dept: "tech"}}, {$group: {_id: "$dept", max_score: {$max: "$score"}}}])，等于把 OLAP 当 OLTP 用，扛不住流量峰。
容易被忽略的边界：同分处理与分页一致性
排行榜最隐蔽的坑不是性能，而是逻辑漂移。比如两个用户同为 900 分，第一次请求返回 A 在前、B 在后，第二次却反过来——这不是 bug，是 MongoDB 默认行为：未指定唯一排序键时，同值文档顺序不确定。
- 解决办法只有两个：
sort({score: -1, _id: 1})或sort({score: -1, created_at: -1, _id: 1})，确保最终排序键组合全局唯一 - 分页时绝对禁止
skip(100).limit(20)：第 6 页起，只要有人新上榜，整页内容就可能重复或丢失（游标失效） - 正确分页用
find({score: {$lt: last_seen_score}}).sort({score: -1}).limit(20)，基于上一页末尾分数做范围查询
分数字段一旦允许负数、小数、或从外部导入（比如 CSV），务必在写入前 validate 类型和范围，否则 $sort 会静默失败——它不会报错，只会按 BSON 类型优先级排（比如字符串 "100"
