MongoDB含$and嵌套$or的查询速度极慢，如何使其命中索引？

核心问题分析 #

你的慢查询本质是$or语句同时包含地理空间条件和普通字段匹配，MongoDB对这类跨不同索引类型的$or查询，合并结果的开销极高，导致总耗时远大于两个单独查询之和。

优化方案 #

1. 使用$unionWith替代$or（推荐） #

利用$unionWith将两个高效的子查询结果合并，既能保留各自的索引效率，又能支持后续的排序、分页操作。示例查询如下：

db.collection.aggregate([
  {
    $unionWith: {
      coll: "collection", // 替换为你的集合名
      pipeline: [
        {
          $match: {
            "After.Start": { "$gte": ISODate("2022-10-28T00:00:00Z") },
            "LongLat": {
              "$geoWithin": {
                "$centerSphere": [[-111.888221740722, 40.760311126708999], 0.012616093290458801]
              }
            }
          }
        }
      ]
    }
  },
  {
    $match: {
      "After.Start": { "$gte": ISODate("2022-10-28T00:00:00Z") },
      "ByPass": { "$in": ["5162e"] }
    }
  },
  // 在此添加排序、分页逻辑
  { $sort: { "After.Start": -1 } },
  { $skip: 0 },
  { $limit: 20 }
])

该方式会分别调用两个子查询的索引快速获取结果，再自动合并去重，总耗时接近两个单独查询的耗时之和。

2. 补充针对性复合索引 #

你已有的LongLat + After.Start复合索引能覆盖地理查询分支，还需要添加针对ByPass分支的复合索引：

db.collection.createIndex({"After.Start": 1, "ByPass": 1})

添加后，MongoDB在处理原$or查询时，会分别使用两个复合索引执行子查询，再合并结果，能大幅降低总耗时。

3. 应用层合并结果（可选） #

如果ByPass匹配的推广项数量较少，可以在应用层先查询出所有符合条件的推广项，再与地理查询结果做内存级合并去重。这种方式适合推广项量级小的场景，能避免数据库层面的合并开销。

内容的提问来源于stack exchange，提问作者runxc1 Bret Ferrier