MongoDB聚合管道实现热点内容排行全攻略

优化 MongoDB 聚合管道的核心原则是：$match 必须置于 $sort 之前，从而充分利用索引加速查询。由于聚合管道采用流式处理方式，先行过滤掉无关数据再执行排序，能够显著降低内存占用与执行耗时。此外，$sort 应紧跟在 $match 之后，且排序字段的类型必须保持一致并结合有效索引，否则 Top-N 查询极易失效，导致性能大幅下降。

直接使用 $sort + $limit 获取 TopN 热点内容，从技术实现上看确实十分简单。但在生产环境中，要想稳定运行并快速响应，关键考验并不在于“能否实现”，而在于“字段是否建立了索引”“排序字段的类型是否统一”“聚合阶段的执行顺序是否科学”。只要其中一个环节被忽视，性能就可能急剧恶化，甚至引发查询超时。

为什么 $sort 必须紧挨着 $match 放？

聚合管道本质上是流式处理，每个阶段产生的数据会直接传递给下一阶段。如果在 $group 之后再进行 $sort，就必须对整个分组结果执行全量排序；而如果先通过 $match 过滤出最近 7 天的数据，再执行 $sort，内存消耗和耗时可能相差几个数量级。

• 错误写法：先执行 $group 统计所有历史热度数据，然后再 $sort —— 即便最终只取前 10 条记录，也会计算全部分组结果，造成大量资源浪费。
• 正确顺序：$match → $sort → $limit（适用于按时间或原始热度字段排序的场景，能最大程度利用索引）。
• 如果必须按计算后的值排序（例如“阅读量 ÷ 发布天数”），则需要在 $addFields 或 $project 之后放置 $sort，这是一种特殊处理方式。

created_at 和 view_count 哪个更适合做排序主字段？

选择哪个字段作为排序依据，完全取决于你对“热点”的定义——是倾向推荐最新发布的内容，还是着重推荐访问量最高的内容？这两种策略的优化方向截然不同。

• 按时间热度（例如“今日新榜”）：使用 created_at 降序排列，搭配索引 db.posts.createIndex({ created_at: -1 })，实现简单高效。
• 按热度值（例如“小时榜”）：使用 view_count 降序排列，但必须确保该字段存储的是数字类型——如果错误地存成了字符串（比如 "12345"），$sort 会按字典序排序，导致 "999" 排在 "10000" 前面，结果完全错乱。
• 混合排序（更贴近真实业务场景）：先按 view_count 降序，当热度相同时再按 created_at 降序，这样能避免老旧内容长期占据榜单。写法示例：{$sort: { view_count: -1, created_at: -1 }}。

聚合里用 $lookup 关联用户信息会影响 TopN 性能吗？

影响非常显著，尤其当被关联集合数据量庞大或缺乏索引时。$lookup 会在 $sort 之前执行，这意味着你需要为所有候选文档执行关联操作，哪怕最终只返回前 10 条结果。这好比在批发市场中，把所有商品逐一搬出来检验，最后只买一个苹果——纯粹浪费性能。

• 安全做法：先通过 $match + $sort + $limit 获取 TopN 的 ID 列表，然后使用 find({ _id: { $in: [...] } }) 单独查询关联详情。这样关联操作仅针对最终结果集，而非全部候选数据。
• 万不得已必须在流水线中使用 $lookup 时，务必确保被关联集合在 localField 上建立了索引（例如 db.users.createIndex({ _id: 1 })）。
• 不要在 $lookup 之后再加 $sort —— 关联结果很可能已经打乱了原始热度顺序，并且后续排序无法利用索引，性能雪上加霜。

真正制约性能的瓶颈，往往不是聚合语法写错，而是 view_count 字段类型不统一、created_at 缺少索引、或者把 $lookup 错误地嵌入到 TopN 主流水线中。上线前使用 explain() 检查执行计划，远比反复调参更加有效。