Cosmos DB按属性过滤数组并聚合的问题排查与性能咨询

首先，我们来逐个拆解你的问题，一步步找到原因和优化方向：

第一种聚合语句报错的原因 #

你在$project中嵌套$filter的写法在Cosmos DB的Mongo API中报错，核心问题是Cosmos DB对MongoDB聚合操作的支持存在兼容性限制。虽然标准MongoDB完全支持在$project里用$filter过滤数组，但Cosmos DB的Mongo兼容层（尤其是较低版本）可能未完全实现该功能，或者对表达式的解析逻辑有差异，导致服务器无法处理该请求。

第二种聚合语句返回空结果的原因 #

你的第二个语句返回空，最直观的问题是集合名称不匹配：第一个语句操作的是db.someCollection，但第二个语句误写成了db.clients——如果你的目标集合是someCollection，这个拼写错误直接导致查询了错误的集合，自然返回空结果。

除此之外，还可以排查这几个细节：

• 确认时间戳比较逻辑：你用的$gt（大于），而List 1的expiresOn是1621560318226，指定阈值是1516620762985，数值上是符合条件的，逻辑没问题；
• 检查字段路径拼写：确保文档中的lists.meta.expiresOn没有拼写错误（比如meta写成metas，expiresOn少写字母）；
• 验证原始文档：先执行db.someCollection.find({ "lists.meta.expiresOn": { $gt: 1516620762985 } })，确认集合中确实存在符合条件的文档。

两种聚合方法的性能对比 #

• 第一种方法（先过滤再Unwind）：性能更优。它先通过$filter剔除数组中不符合条件的元素，再执行$unwind展开数组。这样$unwind处理的是已经精简后的数组，生成的中间文档数量更少，后续$project操作的效率也更高。尤其当集合中文档的lists数组元素较多时，这种写法能显著减少数据处理量。
• 第二种方法（先Unwind再过滤）：性能较差。$unwind会先把所有数组元素展开成独立文档，哪怕这些元素根本不符合过滤条件，之后再用$match筛选。如果数组规模大，会产生大量不必要的中间文档，占用更多计算资源和时间，数据量越大，性能差距越明显。

修正后的可行方案 #

方案1：修正第二种方法的集合名称 #

把集合名改成正确的someCollection，语句如下：

db.someCollection.aggregate([
  { $unwind: '$lists'},
  { $match: { 'lists.meta.expiresOn': { $gt: 1516620762985 } } },
  { $project : { _id:0, name: '$lists.name' } }
])

集合名正确的情况下，这个语句应该能返回你预期的结果。

方案2：兼容版的“先过滤再展开”写法 #

如果想保留高性能的逻辑，可以尝试用$addFields替代$project来使用$filter（部分Cosmos DB版本支持这种写法）：

db.someCollection.aggregate([
  { 
    $addFields: { 
      filteredLists: { 
        $filter: { 
          input: "$lists", 
          as: "list", 
          cond: { $gte: [ "$$list.meta.expiresOn", 1516620762985 ] } 
        } 
      } 
    } 
  },
  { $unwind :'$filteredLists'},
  { $project : { _id:0, name: '$filteredLists.name' } }
])

如果还是报错，建议检查你的Cosmos DB Mongo API兼容版本，升级到3.6或更高版本（更高版本对MongoDB聚合操作的支持更完善）。

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