正确去重需两层$group:首层用复合_id(如{user_id:"$user_id",com_id:"$com_id"})分组并$first取代表文档;次层按user_id分组,用$sum统计comNums等汇总字段,且$sort必须在$group前、$skip/$limit在次层$group后。

用 $group 对多条子文档做去重分组,关键在 _id 设计
一对多关系(比如一个 user_id 对应多个 com_id)要做去重,本质不是删数据,而是“按主键组合分组 + 每组只取一条代表”。$group 的 _id 必须包含能唯一标识“逻辑主记录”的字段,例如 { user_id: "$user_id", com_id: "$com_id" }。如果只写 "$user_id",那后续再 $group 一次才能聚合到用户级,但中间会丢失原始明细的关联性。
常见错误是直接对 user_id 分组后用 $first 取任意一条 com_id,结果看似去重了,实则把不同 com_id 合并成了一条,造成业务数据丢失。
- 正确做法:第一层
$group用复合_id(如{ user_id: "$user_id", com_id: "$com_id" }),确保每组只含同一 user+com 组合的文档 - 再用
$first或$max提取该组内最新/最全的字段(如"name": { "$first": "$name" }) - 若需最终按 user 汇总(如统计该用户关联多少个 com),必须加第二层
$group,以"$user_id"为_id,再用$sum: 1算comNums
$first 和 $last 依赖前置 $sort,不排序就是随机取
很多人以为 $first 是取“最早插入”的那条,其实它只取管道中当前顺序的第一条——而这个顺序由上一阶段决定。如果没显式 $sort,MongoDB 不保证文档返回顺序,$first 结果不可控。
例如想保留每个 unique_path 下 modified 最新的那条记录,必须先 { "$sort": { "unique_path": 1, "modified": -1 } },再 $group 时用 "$first": "$$ROOT" 才可靠。
- 排序字段要包含分组键(如
unique_path)和时间/优先级字段(如modified),否则跨组排序无意义 - 如果业务要求“取创建时间最早的”,就用
"modified": 1升序,再配$first - Spring Data MongoDB 中,
Aggregation.sort()必须放在Aggregation.group()前面,否则无效
分页必须放在最后两层 $group 之后,否则跳过的是分组前的原始文档
聚合里 $skip / $limit 的位置极其关键。如果把它们插在第一次 $group 后、第二次 $group 前,相当于对“user+com”粒度的结果分页,而不是对最终“user”粒度的结果分页——页面数和总数对不上,前端翻页会漏数据或重复。
典型结构是:match → sort → group(user+com)→ group(user)→ skip/limit → sort(最终排序)。其中最终 sort 也得放在 skip/limit 后面,否则排序被截断。
- Spring Boot 中,
Aggregation.skip()和Aggregation.limit()要紧贴在第二次$group之后、最终Aggregation.sort()之前 - 分页参数计算:若每页 10 条,第 3 页应为
skip(20),不是skip(30);注意(pageNum - 1) * pageSize别算错 - 别在
$match阶段用$in传超大数组(如几万 user_id),可能触发 BSON 大小限制或慢查询,考虑拆批或建索引
去重后汇总字段(如 serverNums)要用 $sum,别误用 $first
汇总类字段(总数、金额、数量等)必须用 $sum 累加,不能用 $first 或 $max 替代。前者是聚合语义,后者只是取值语义。
比如一个 user 有 3 条记录,server_nums 分别是 5、8、3,期望汇总值是 16。如果第二层 $group 写成 "serverNums": { "$first": "$serverNums" },结果永远是 5;而 "serverNums": { "$sum": "$serverNums" } 才正确。
-
$sum支持字段路径("$server_nums")和常量(1),后者常用于计数(如"comNums": { "$sum": 1 }) - 如果字段可能为 null,
$sum会跳过,无需额外$cond判断;但$first遇到 null 也会照取,可能污染结果 - 涉及浮点数累加要注意精度,MongoDB 默认 double,业务敏感场景建议在应用层校验或转整型存储
实际执行时最容易被忽略的是:两次 $group 之间的字段投影是否完整。第一层分组后,若没用 $first 把 name、dept_names 等字段带出来,第二层就无法访问——这些字段不会自动继承,必须显式声明。











