优化 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() 检查执行计划，远比反复调参更加有效。
