MongoDB聚合查询优化：提取指定教师授课的主/子科目

我来帮你梳理下这个MongoDB查询的问题，结合你的需求和尝试的方案，给你详细解答：

先明确你的需求与文档结构 #

你的文档结构简化后如下：

// 示例文档1
{ 
  "_id" : ObjectId("5ae84dd87f5b72618ba7a669"), 
  "main_sub" : "MATHS", 
  "reporting" : [ { "teacher" : "ABC" } ], 
  "subs" : [ { "sub" : "GEOMETRIC", "teacher" : "XYZ" } ] 
}
// 示例文档2
{ 
  "_id" : ObjectId("5ae84dd87f5b72618ba7a66a"), 
  "main_sub" : "SOCIAL SCIENCE", 
  "reporting" : [ { "teacher" : "XYZ" } ], 
  "subs" : [ { "sub" : "CIVIL", "teacher" : "ABC" } ] 
}

需求是：提取指定教师（比如ABC）授课的所有科目，标记该科目是否为父科目，最终得到类似这样的结构：

[
  {'subject':'MATHS', 'is_parent':true}, 
  {'subject':'CIVIL', 'is_parent':false}
]

1. 最高效的查询语句是什么？ #

你之前尝试的$project结合$cond会重复编写条件，这里推荐一个更高效且逻辑清晰的聚合管道，能避免重复条件，还能提前过滤数据提升性能：

db.collection.aggregate([
  // 第一步：过滤出包含目标教师的文档，减少后续计算量（核心性能优化）
  {$match: {
    $or: [
      {"reporting.teacher": "ABC"},
      {"subs.teacher": "ABC"}
    ]
  }},
  // 第二步：分别处理父科目和子科目的匹配结果
  {$project: {
    // 处理父科目：如果教师在reporting数组中，生成父科目条目，否则空数组
    parentSubjects: {
      $cond: [
        {$in: ["ABC", "$reporting.teacher"]},
        [{subject: "$main_sub", is_parent: true}],
        []
      ]
    },
    // 处理子科目：先筛选出教师匹配的子科目，再转换成目标结构
    childSubjects: {
      $map: {
        input: {$filter: {
          input: "$subs",
          cond: {$eq: ["$$this.teacher", "ABC"]}
        }},
        as: "subItem",
        in: {subject: "$$subItem.sub", is_parent: false}
      }
    }
  }},
  // 第三步：合并父、子科目数组
  {$project: {
    allSubjects: {$concatArrays: ["$parentSubjects", "$childSubjects"]}
  }},
  // 可选：如果需要将数组拆分为单个文档，执行以下两步
  {$unwind: "$allSubjects"},
  {$replaceRoot: {newRoot: "$allSubjects"}}
])

这个方案的优势：

• 性能优先：开头的$match直接过滤掉无关文档，避免后续处理不必要的数据，如果你给reporting.teacher和subs.teacher建立索引，这一步会更快
• 逻辑清晰：父科目和子科目分开处理，不需要重复编写条件判断
• 灵活输出：如果不需要单个文档的格式，可跳过最后两步，直接提取allSubjects字段就能得到目标数组

2. 此类计算适合在MongoDB还是服务器代码处理？ #

这个要根据你的实际场景判断：

优先选择MongoDB查询的场景：

• 数据量较大：服务器端处理需要传输大量原始文档，网络开销大，而MongoDB可以在数据库层面直接过滤和转换数据
• 可利用索引优化：给reporting.teacher和subs.teacher建索引后，$match阶段的性能会大幅提升
• 需要复用查询逻辑：后续如果有其他业务需要类似的科目提取，直接复用这个聚合管道即可

适合服务器端处理的场景：

• 业务逻辑复杂：如果后续需要和其他数据源关联、或者有更复杂的条件判断，MongoDB聚合管道难以实现
• 数据量极小：传输和处理的开销可以忽略，服务器端代码可能更易维护
• 已有成熟的服务器端处理逻辑：不需要额外维护数据库查询代码

针对你的需求，逻辑简单且MongoDB完全可以高效实现，推荐在MongoDB中完成查询，尤其是数据量较大时，能节省大量的网络和服务器资源。

内容的提问来源于stack exchange，提问作者Bhumi Singhal