做LBS（基于位置的服务）项目，最让人头秃的不是算法多难，而是数据量上来后，查询慢得像蜗牛，甚至直接崩盘。我见过太多团队一开始为了省事，用传统关系型数据库硬扛经纬度查询，结果服务器CPU飙到100%，运维半夜被电话叫醒，那种绝望谁懂。今天不聊虚的，直接上干货，讲讲我在实际项目中踩过的坑，以及为什么 geo mongo 方案才是很多中小团队的救命稻草。
记得三年前，我们接了一个同城配送的急单，要求用户能实时看到周围5公里内的骑手。刚开始为了赶进度，直接用了MySQL的普通索引加距离计算。数据量在1万条的时候，一切正常，页面加载也就200毫秒。但当并发上来，数据量突破50万后，问题就暴露了。每次搜索都要全表扫描或者大范围索引扫描，响应时间直接飙升到3秒以上。老板在群里骂娘，用户投诉电话被打爆。那时候我才意识到，传统方案在海量空间数据面前，简直就是拿大刀砍坦克。
后来我们果断重构，引入了 MongoDB 的地理空间索引。这里有个误区，很多人觉得 geo mongo 就是简单的把经纬度存进去，其实没那么简单。MongoDB 提供两种主要的地理空间索引类型：2dsphere 和 2d。对于球面地球模型，必须用 2dsphere，它基于球面几何，计算更准确。如果你用了 2d 索引，在高纬度地区误差会非常大，甚至出现“穿越”现象。我在第一次迁移时，因为偷懒没改索引类型，导致北京的用户搜到了广州的骑手，这种低级错误差点让我背锅。
关于性能，真实数据说话。重构后，同样的查询场景，响应时间稳定在50毫秒以内。当然，这不是说 MongoDB 就完美无缺。我在配置过程中，差点掉进一个坑：TTL索引和地理空间索引的冲突。有些业务场景需要自动清理过期数据，比如骑手接单后的超时未支付订单。我试图在一个集合上同时建立TTL索引和2dsphere索引，结果发现TTL索引并不支持地理空间查询的优化，导致删除操作依然缓慢。后来我采取了分集合策略，将活跃数据和历史数据分开，虽然增加了维护成本，但查询效率确实提升了。
再说说成本。很多老板一听 MongoDB 就摇头，觉得贵。其实，对于大多数LBS应用，MongoDB 的社区版完全免费，而且其水平扩展能力很强。在同等硬件配置下，MongoDB 处理空间查询的性能通常是 MySQL 的5到10倍。这意味着你可以用更少的服务器支撑更多的用户，长期来看，服务器成本反而降低了。当然，运维复杂度会增加，需要有人懂 MongoDB 的底层原理，比如分片策略、副本集配置等。
还有一个容易被忽视的细节：数据精度。MongoDB 存储经纬度时，默认使用双精度浮点数，精度足够日常使用。但如果你需要厘米级的精度，比如自动驾驶或高精度地图，可能需要额外处理。另外，在插入数据时，务必确保坐标格式正确，[经度, 纬度]，千万别写反了，否则查询结果会完全错误。我见过有人把 [纬度, 经度] 存进去，结果查出来的位置都在海里，这种低级错误在代码审查时根本看不出来，只能靠测试数据验证。
最后，给个真实建议。如果你的项目还在用 MySQL 扛 LBS 查询，且数据量超过10万，或者并发较高，建议尽早评估迁移到 MongoDB。不要等到系统崩了再救火。在选型时，一定要做压力测试，模拟真实场景下的并发查询。同时，做好监控，关注慢查询日志，及时调整索引策略。 geo mongo 方案不是银弹，但它确实能解决大部分空间查询的性能瓶颈。
如果你正在纠结数据库选型，或者遇到 MongoDB 性能调优的问题，欢迎随时交流。毕竟，踩过的坑越多，路走得越稳。别等上线了才后悔，那时候哭都来不及。
