如何利用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() 查看执行计划，比反复调参数更有效。