MongoDB地理空间+_id复合索引创建及不生效问题排查

问题现象 #

我有一个逻辑简单的MongoDB查询，始终无法通过创建合适的索引达到最优读取性能，也无法引导MongoDB使用我创建的自定义索引，查询语句如下：

const query = {
  'location.geoJson': {
    $geoWithin: {
      $centerSphere: [
        user.location.geoJson.coordinates,
        defaultRadiusInMiles / earthRadiusInMiles,
      ],
    },
  },
  _id: { $lt: lastId },
};

results = collections.myCollection.find(query).sort({ _id: -1 }).limit(limit);

为提升查询效率，我创建了如下复合索引：

collections.myCollection.createIndex({ 'location.geoJson': '2dsphere', _id: -1 })

但查看explainStats结果时，发现MongoDB选择的执行计划如下：

"winningPlan": {
      "stage": "LIMIT",
      ...
      "inputStage": {
        "stage": "FETCH",
        "filter": {
          "location.geoJson": {
            "$geoWithin": {
              "$centerSphere": [
              ...
              ]
            }
          }
        },
        "inputStage": {
          "stage": "IXSCAN",
          "keyPattern": {
            "_id": 1
          },
          "indexName": "_id_",

根据官方文档说明，该执行计划表示MongoDB会先对_id做索引扫描，再根据location条件过滤匹配文档，最后做结果限制，完全不符合预期。

现有疑问 #

• 是不是我创建的复合索引本身有错误，无法支持该查询？要如何强制MongoDB使用我创建的复合索引？
• queryPlanner显示解析后的查询结构是两个条件组成的$and，且第一个元素是_id条件，是不是因为这个顺序导致查询优化器优先执行_id相关逻辑？

  "parsedQuery": {
        "$and": [
          {
            "_id": {
              "$lt": ...
            }
          },
          {
            "location.geoJson": {
              "$geoWithin": {
                "$centerSphere": [
                  ...
                ]
              }
            }
          }
        ]
      },
  

• 我当前实现的是从新到旧的游标分页逻辑，传入ObjectId作为分页游标：拉取第一页（最新的limit条帖子）时传入ObjectId('f'.repeat(24))作为lastId，此时出现性能问题。我确认查询半径内共有110条匹配文档，拉取第一页时即使limit小于110，也会扫描全部110条文档；但拉取下一页（传入第一页最后一条记录的ObjectId作为lastId）时，不会扫描全部110条文档，性能极高，仅扫描limit数量的文档和索引键。为什么两页查询性能差异这么大？
• 如果当前方案存在缺陷，有没有其他可落地的从新到旧分页实现方案建议？

原因与解决方案 #

索引不被选中的核心原因 #

你创建的复合索引没有语法错误，MongoDB选择默认_id索引和$and条件的顺序无关，完全是查询优化器基于代价估算的结果。
两种索引的执行逻辑差异：

• 你创建的{'location.geoJson': '2dsphere', _id: -1}索引：先通过2dsphere索引圈定所有地理范围内的文档，再按索引中存储的_id倒序匹配_id < lastId的条件，凑够limit条返回。
• 默认_id_索引：从集合中最大的_id开始倒序扫描，逐个拉取文档检查是否落在地理范围内，凑够limit条就终止扫描。

第一页传入的lastId是理论最大值ObjectId('f'.repeat(24))时，优化器会预判：走_id索引只要扫到limit个符合地理条件的文档就能返回，代价比先圈出所有110条地理范围文档再排序取数更低，因此主动选择了_id索引。但实际场景中最新的大量文档并不在查询半径内，优化器的估算失真，最终扫描了远超limit数量的文档才凑够结果，导致性能差。
第二页性能正常是因为传入的lastId是真实存在的业务文档ID，优化器对_id索引的代价估算升高；同时走复合地理索引时，从该ID位置向后遍历很快就能凑够limit条，不需要扫完所有110条范围文档，因此执行效率高。

强制使用自定义索引的方法 #

直接在查询后追加hint()方法，跳过优化器的代价估算，强制MongoDB使用你创建的复合索引即可：

results = collections.myCollection.find(query)
  .hint({ 'location.geoJson': '2dsphere', _id: -1 })
  .sort({ _id: -1 })
  .limit(limit);

加hint后第一页查询会直接定位地理范围内的所有文档，按_id倒序取前limit条，不会扫描范围外的文档，性能稳定。

分页优化建议 #

• 若业务查询半径固定、范围内文档量始终保持在百级别，直接加hint强制走上述复合索引即可，性能够用。
• 若后续查询半径可能扩大、范围内文档量涨到数千甚至数万，可以采用GeoHash分桶方案：将地理空间按业务所需精度切为固定网格，每个网格预存对应范围内按_id倒序排列的文档列表，查询时先计算出覆盖查询半径的所有网格，直接从对应网格按游标取数，能大幅降低扫描量。
• 第一页查询不要传入虚拟的最大ObjectId，直接去掉_id过滤条件，仅保留地理范围条件、按_id: -1排序取limit条即可，能避免虚拟边界值导致的优化器估算偏差。

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