MongoDB多GeoNear请求性能优化求助：百万坐标匹配慢

针对你用MongoDB处理百万坐标匹配复杂多边形的性能问题，给出以下优化方向：

1. 替换查询操作符，贴合实际需求 #

你当前用$near配合$maxDistance:0来匹配包含点的多边形，本质是用错了操作符——$near核心是找最近的几何图形，而非判断点是否在多边形内。换成专门处理几何相交的$geoIntersects，能让MongoDB使用更高效的空间查询逻辑：

const res = await collectionA
    .find({
        geometry: {
            $geoIntersects: {
                $geometry: { type: "Point", coordinates: [location.longitude, location.latitude] }
            }
        }
    })
    .project({ _id: 1 })
    .toArray();

同时必须确保collectionA的geometry字段已建立2dsphere索引，这是空间查询的基础：

await collectionA.createIndex({ geometry: "2dsphere" });

2. 批量处理，消除百万次网络往返 #

当前逐个查询百万坐标的方式会产生百万次网络请求，这是性能瓶颈的核心。推荐直接在MongoDB内完成批量匹配：
如果collectionB已在Mongo中，用聚合管道的$lookup结合空间条件做批量关联：

db.collectionB.aggregate([
  {
    $lookup: {
      from: "collectionA",
      let: { point: { type: "Point", coordinates: ["$location.longitude", "$location.latitude"] } },
      pipeline: [
        {
          $match: {
            $expr: {
              $geoIntersects: {
                geometry: "$$point"
              }
            }
          }
        },
        { $project: { _id: 1 } }
      ],
      as: "matchedPolygons"
    }
  }
]);

这种方式一次性处理所有collectionB文档，彻底避免多次网络通信的开销。

3. 应用层缓存，复用重复查询结果 #

既然重复查询同一位置无性能提升，说明MongoDB的查询缓存未生效（可能因查询参数的微小差异或缓存策略限制）。在应用层加缓存（比如Redis）：

• 将经纬度转为字符串（如"lon,lat"）作为key
• 匹配到的多边形_id数组作为value
• 后续查询先查缓存，命中则直接返回，未命中再查MongoDB

4. 简化复杂多边形，降低查询计算量 #

每个MultiPolygon含数千顶点，会极大增加空间查询的计算成本。用地理工具（如Turf.js）简化多边形：

import { simplify } from '@turf/turf';

// 简化多边形，保留90%的形状，可调整tolerance参数平衡精度与性能
const simplifiedPolygon = simplify(originalMultiPolygon, { tolerance: 0.001, highQuality: true });

简化后的多边形顶点数大幅减少，MongoDB的索引构建和查询速度都会显著提升，同时基本不会影响点-in-polygon的判断准确性。

5. 预计算映射结果（静态数据场景） #

如果collectionB的坐标是静态/更新频率低的，直接预计算所有坐标对应的多边形，将结果存储在collectionB的文档中（新增字段如matchedPolygonIds），或者单独建立映射集合。后续业务直接读取预计算结果，无需再执行空间查询。

6. 调整MongoDB配置，提升硬件利用率 #

• 确保MongoDB的内存足够容纳2dsphere索引，避免频繁磁盘IO（可通过db.collectionA.getIndexes()查看索引大小，调整wiredTigerCacheSizeGB参数）
• 调大Node.js驱动的连接池大小（如MongoClient.connect时设置poolSize: 20），避免因等待连接导致的idling状态

替代方案：内存中本地计算 #

如果以上优化仍无法满足性能要求，可以放弃MongoDB，改用内存中处理：

1. 将collectionA的所有多边形加载到内存
2. 用RTree空间索引（如@turf/rtree）对多边形做预处理，提升查询效率
3. 遍历collectionB的坐标，用Turf.js的booleanPointInPolygon或RTree查询匹配的多边形

这种方式避免了网络开销，查询速度会大幅提升，但需要注意内存占用（2000个复杂多边形可能需要几百MB内存，需根据服务器配置调整）。

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