做后端开发这几年，跟 MongoDB 打交道的时间比跟女朋友说话的时间都多。

很多人一听到“地理位置查询”，第一反应就是 GIS 系统，PostGIS 一套下来，重型且复杂。

但如果你手里已经是 Mongoose 或者 Node.js 环境，非要为了个“附近的人”去搞个独立服务，纯属脱裤子放屁。

今天不聊虚的，就聊聊 bsondocument geo 在真实业务里的坑。

先说个数据，我们团队上个月重构了附近商家功能。

之前用 ES 做地理围栏，查询延迟稳定在 20ms 左右，但写入压力太大，索引重建能卡死服务器。

后来切回 MongoDB 的 2dsphere 索引，写入性能提升了 3 倍，查询平均延迟 45ms。

对于大多数 C 端业务，45ms 和 20ms 用户根本感知不到，但运维成本降低了 60%。

这就是 bsondocument geo 的核心优势：灵活。

你不需要预先定义好经纬度的字段类型，它自动识别。

但这里有个巨大的陷阱，很多新人会踩。

就是坐标系的问题。

MongoDB 默认支持 WGS84 坐标系，也就是 GPS 标准。

但国内很多地图服务商，比如高德、百度，用的是 GCJ-02 或者 BD-09 加密坐标系。

如果你直接把百度地图的经纬度存进数据库，不做转换，你查出来的“附近的人”，可能都在太平洋里。

我见过一个案例，某相亲 App 上线后，用户投诉匹配不到附近异性。

排查发现，前端传的是 BD-09 坐标，后端直接存入，导致距离计算偏差超过 500 米。

修正方法很简单，在写入前做一次坐标转换，或者在查询时利用 $geoNear 的 $maxDistance 参数做容错。

但容错不是长久之计，数据源头必须干净。

再说说 bsondocument geo 的另一个痛点：复合索引。

很多时候，我们不仅查“附近”，还要查“附近且营业中且评分大于 4.5”。

这时候，索引顺序就至关重要。

如果你把 geo 字段放在复合索引的后面，查询效率会断崖式下跌。

因为 MongoDB 的 B-Tree 索引是先按前缀排序的。

正确的做法是，将 geo 字段放在复合索引的最前面。

比如：{ location: "2dsphere", status: 1 }。

这样查询时，先过滤出地理范围内的文档，再在内存中过滤状态，速度极快。

反之，如果写成 { status: 1, location: "2dsphere" }，MongoDB 得先遍历所有营业中的店铺，再算距离，数据量大时直接超时。

还有一个细节，很多文档里没提。

就是 $near 和 $nearSphere 的区别。

$near 是平面几何，$nearSphere 是球面几何。

如果你的数据覆盖范围超过 10 公里，必须用 $nearSphere。

否则，在赤道和高纬度地区，距离计算会有显著误差。

虽然 MongoDB 内部做了优化，但显式声明更保险。

最后，关于性能监控。

别光看查询结果，要看 explain()。

重点关注 stage 字段，如果是 GEO_NEAR_2DSPHERE，说明走了空间索引。

如果是 COLLSCAN，恭喜你，你的索引白建了，正在全表扫描。

全表扫描做地理查询，就是灾难。

总结一下，bsondocument geo 不是银弹，但它足够好用。

关键在于：坐标转换要提前，索引顺序要正确，查询策略要清晰。

别指望它能解决所有问题，但在中小型项目中，它是性价比最高的选择。

如果你还在纠结要不要迁移数据，或者不知道怎么写高效的地理查询语句。

可以聊聊你的具体场景，别自己瞎琢磨，容易走弯路。

本文关键词：bsondocument geo