MongoDB 聚合管道里经常会出现“按分组取排序后最后几条”的需求。比如统计每个商品分类中销售额最低的 3 个商品、每个班级中成绩垫底的 5 名学生，或者每个服务节点上响应时间最慢的几条日志。过去这类需求通常要组合 $sort、$group、$project 甚至 $unwind 才能完成，代码层级一多就容易把排序方向写反。MongoDB 5.2 引入的 $bottomN 累加器就是专门用来在分组内按指定顺序截取底部 N 条记录的表达式，它让这类查询可以写得更直接，也更不容易出错。
一、$bottomN 的定位与典型场景
$bottomN 不是独立的聚合管道阶段，而是用于 $group 或 $setWindowFields 阶段的累加器表达式。它的作用是：先对组内文档执行排序，然后从排序结果的底部开始取 N 个元素返回。这里“底部”由 sortBy 的排序方向决定，而不是简单指插入顺序靠后的文档。
以一个销售集合为例，集合中每条文档记录一个商品的一次销售统计，包含 category、product、sales 三个字段。如果需求是找出每个分类中销售额最低的三个商品，传统写法需要先按分类和销售额排序，再用 $group 把商品压入数组，最后用 $project 截断数组。这种方式虽然能实现，但阶段比较多，而且一旦后续需求改为取前几条，排序方向要同步调整，比较繁琐。
$bottomN 把“排序”和“截取底部 N 条”压缩到一个表达式中。开发者只需要在 $group 里写明 n 值、排序字段以及输出内容，聚合引擎就会在分组内部完成剩余工作。对于需要“每组底部若干条记录”的报表，它减少了流水线阶段，也让意图更加清晰。
二、$bottomN 的核心语法与参数细节
$bottomN 的完整语法结构如下：
{
$bottomN: {
n: <number>,
sortBy: { <field1>: <sort order> },
output: <expression>
}
}
其中 n 表示每组要返回的元素个数，必须是正整数。如果 n 超过组内文档数量，$bottomN 会把整组文档全部返回，不会报错。sortBy 是一个排序文档，语法与 $sort 阶段一致，1 表示升序，-1 表示降序。output 则控制每个元素的输出形式，可以写字段路径，也可以写文档表达式，还可以嵌入聚合表达式。
最容易出错的是 sortBy 的方向。假设业务目标是“取销售额最低的 3 个商品”，就应该写 sortBy: { sales: -1 }。因为 -1 表示按销售额降序排列，大值排在前面，小值落在底部，$bottomN 再从底部截取，自然拿到最低的 3 条。反过来如果写成升序，底部就是销售额最高的记录。
如果 sortBy 字段存在大量相同值，仅按该字段排序可能无法保证稳定返回，具体返回哪些底部记录可能随执行计划变化。为了让结果可预期，可以在 sortBy 中追加唯一字段作为次级排序条件，比如 sortBy: { sales: -1, _id: 1 }。这样即使销售额相同，也会按 _id 升序稳定决定顺序。
另外 output 不一定是单个字段。比如想同时返回商品名和销售额，可以写成 output: { product: "$product", sales: "$sales" }。这种方式比先取完整文档再在应用层裁剪更省网络传输。
三、实战：按分类取销售额最低的后 N 条记录
下面构造一个简单的销售数据集合：
db.sales.insertMany([
{ _id: 1, category: "手机", product: "手机A", sales: 120 },
{ _id: 2, category: "手机", product: "手机B", sales: 80 },
{ _id: 3, category: "手机", product: "手机C", sales: 95 },
{ _id: 4, category: "电脑", product: "电脑A", sales: 300 },
{ _id: 5, category: "电脑", product: "电脑B", sales: 150 },
{ _id: 6, category: "电脑", product: "电脑C", sales: 420 },
{ _id: 7, category: "手机", product: "手机D", sales: 60 }
])
执行下面的聚合查询，可以一次拿到每个分类销售额最低的 3 个商品：
db.sales.aggregate([
{
$group: {
_id: "$category",
lowestThree: {
$bottomN: {
n: 3,
sortBy: { sales: -1 },
output: { product: "$product", sales: "$sales" }
}
}
}
}
])
查询结果大致如下：手机分类返回手机D、手机B、手机C，销售额分别为 60、80、95；电脑分类只有 3 条记录，所以全部返回，顺序为电脑B、电脑A、电脑C。可以看到，虽然原始插入顺序不是按销售额排列的，$bottomN 仍然按照 sortBy 指定的规则重新排序并截取，这正是它和 $lastN 的关键差异。
如果只需要商品名称，可以把 output 简化为 "$product"，返回结果会变成一个字符串数组。如果 n 值需要动态决定，也可以从文档字段或表达式传入，但实际项目中建议先确认分组内数据规模，避免过大的 n 导致返回数组膨胀。
四、$bottomN 与 $sort 加 $limit、$lastN 的选择
传统写法通常先 $sort 让数据全局有序，再 $group 和 $push 收集数组，最后用 $slice 截取前 N 条。下面是一个等价示例，按分类和销售额升序排序，这样组内最低的 3 条会排在最前面，再取数组前 3 个元素：
db.sales.aggregate([
{ $sort: { category: 1, sales: 1 } },
{
$group: {
_id: "$category",
products: { $push: "$$ROOT" }
}
},
{
$project: {
lowestThree: { $slice: [ "$products", 3 ] }
}
}
])
这种写法可以得到相同结果，但阶段更长。它依赖 $sort 在 $group 之前完成排序，并且 $push 会保留输入顺序。若数据量很大，$push 会把每个分组的全部文档都组装成数组，然后再从内存里截断，而 $bottomN 只保留符合要求的 N 个元素，不需要把组内所有文档都塞进一个数组。因此从内存占用的角度看，$bottomN 通常更有优势。
再看 $lastN。$lastN 也是从分组中取后 N 个元素，但它不排序，只按文档的输入顺序截取。如果数据在写入时已经按业务需要的顺序排列，$lastN 足够；如果写入顺序和业务排序无关，就必须使用 $bottomN。简单理解：$lastN 关心文档进来的顺序，$bottomN 关心 sortBy 指定的排序顺序。
还有 $bottom，它可以理解为 $bottomN 的 n 等于 1 时的单元素版本。不过 $bottom 返回的是单个值或对象，而 $bottomN 返回数组。实际开发中如果需要一组底部记录，优先选择 $bottomN；如果只要最后一名，用 $bottom 会让结果更加简洁。
在 MongoDB 5.2 以下版本中，这些累加器不可用，只能继续使用多阶段 $sort 加 $group 加 $slice 的写法。升级版本后，可以先在查询侧用 $bottomN 简化复杂分组统计代码，再观察执行计划，判断是否需要为 sortBy 字段建立合适的索引。需要特别留意，$bottomN 虽然减少了流水线阶段，但组内排序依旧有成本，每组基数很大时要结合业务限制 n 的值，避免返回过多无用数据。