MongoDB中$maxDistance仅变化1米时$near查询结果不一致问题及相关疑问

1. 1米maxDistance差异引发查询结果剧变的原因 #

先结合你的执行统计来看：

• 当$maxDistance设为3724073米时：totalKeysExamined:4，totalDocsExamined:0——意味着索引扫描后没有匹配的有效文档返回
• 仅增加1米到3724074米时：totalKeysExamined:56473，totalDocsExamined:56471——突然出现大量匹配文档

这种反常情况主要和MongoDB 2dSphere索引的特性有关：

• 球面距离计算的边界效应：2dSphere索引基于WGS84球面模型计算距离，当查询距离极大（你的3724公里接近地球周长的1/10），1米的差值刚好让查询范围跨过了索引分片的临界边界——原本被索引判定为超出范围的海量文档，刚好被纳入新的距离阈值内。
• 排除数据密集分布的可能（你提到数据跨多个国家），更大概率是索引在大距离场景下的近似计算导致了这种"临界跳跃"。

你可以用$geoNear聚合验证新增文档的实际距离：

db.collection.aggregate([
  {
    $geoNear: {
      near: { type: "Point", coordinates: [12.0, 0.2] },
      distanceField: "calculatedDistance",
      maxDistance: 3724074,
      spherical: true
    }
  },
  { $limit: 100 }
])

这个查询会返回每个匹配文档的精确距离，帮你确认这些文档是否真的落在3724073-3724074米的区间内。

2. $near为何不在索引扫描阶段应用limit？ #

这是由$near的设计逻辑决定的：

• $near的核心特性是按距离由近及远返回结果，MongoDB需要先找到所有符合$maxDistance的文档，计算它们与查询点的精确距离并完成排序，之后才能应用limit返回前N条结果。
• 在MongoDB 4.4版本中，2dSphere索引存储的是地理空间分片信息，并非按距离排序的键值。因此无法在索引扫描阶段直接按距离顺序截取结果，必须先扫描所有符合距离条件的索引键，再对关联文档做距离计算、排序，最后截断到limit的数量。

补充：你的第一个查询totalDocsExamined:0，说明索引扫描的4个键对应的文档要么已被删除，要么不符合隐性过滤条件，所以直接返回空结果，执行时间为0；而第二个查询需要处理大量文档的距离计算和排序，因此执行时间骤增。

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