MongoDB聚合多条件$geoNear查询性能优化方法

• $geoNear是地理查询专用阶段，执行逻辑和普通$match完全不同：它强制要求作为聚合管道第一个阶段，默认优先遍历2d/2dsphere地理索引覆盖的所有文档，按距离排序后，再逐行套用query参数里写的过滤条件，这个过程默认不会复用非地理字段的普通索引，扫描行数极大。
• 单独使用$match时，MongoDB查询优化器会自动选择区分度最高的索引，先通过$in/$lte/$gte条件快速过滤出极小的符合条件的结果集，扫描行数和前者差几个数量级，耗时自然差很多。
• 额外注意：MongoDB 4.4及更早版本中，$geoNear的query参数内的过滤条件完全无法命中索引，哪怕对应字段建了索引也会逐行回表校验，慢查询是必然结果。

• 建适配$geoNear的联合地理索引
  不要把普通过滤条件都塞在query参数里靠逐行校验过滤，把所有用到的过滤字段和地理字段共同建2dsphere联合索引，字段排序规则为：高选择性等值匹配字段（对应$in操作的字段）> 范围匹配字段（对应$lte/$gte操作的字段）> 地理空间字段。建完后$geoNear会在索引遍历阶段直接过滤不符合条件的文档，不需要回表校验。
• 缩小初始地理扫描范围
  必须给$geoNear配置合理的maxDistance参数，把初始扫描的地理半径限制在业务可接受的最小值，从根源上减少需要遍历的文档基数，禁止无半径限制扫描全量地理数据。
• 升级MongoDB版本
  把实例升级到5.0及以上LTS版本，新版本重构了$geoNear的索引命中逻辑，query参数内的过滤条件可以自动复用对应字段的普通索引，不需要强制把所有过滤字段加入地理联合索引。
• 拆分查询逻辑（极端性能场景使用）
  如果以上优化后性能仍不达标，可以拆分两步执行：第一步用普通$match走非地理字段的索引，捞出所有符合业务条件的文档主键；第二步在$geoNear阶段追加_id: {$in: 第一步拿到的主键列表}的过滤条件，此时需要扫描的文档量和纯$match场景基本一致，性能差距会被抹平。

优化后用explain("executionStats")查看执行计划校验效果，重点关注totalDocsExamined指标，当该值和最终返回结果数处于同一量级时，查询耗时基本可以压到50ms以内。

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