干这行七年了，真心觉得做LBS（基于位置的服务）最头疼的不是找数据，而是怎么让数据跑得飞快。特别是那个 mongodb geo距离排序，刚开始我也觉得挺简单，建个索引，查个距离，完事。结果呢？生产环境一压测，CPU直接飙红，接口响应慢得让人想砸键盘。

那天晚上十点，老板在群里@我，说APP上“附近的人”功能卡得动不了。我一看监控，好家伙，查询耗时两秒多。两秒啊，用户早就划走去看下一个了。我赶紧去查日志，发现是个典型的索引没建对的问题。很多人以为随便建个2dsphere索引就万事大吉，其实里面水深得吓人。

首先，你得搞清楚你的数据量级。如果你只有几千条数据，随便查都没事。但要是几十万、上百万条，还在那儿用 $near 排序，那就是在自杀。$near 操作虽然方便，但它会扫描大量文档，效率极低。我之前的项目里，有个同事为了图省事，直接在代码里用 $near 做排序，结果每次查询都要全表扫描一遍索引，服务器风扇转得跟直升机一样。

解决办法其实挺简单的，但很多人不愿意动脑子。第一步，确保你建的是 2dsphere 索引。别搞错了，2d 索引已经过时了，不支持球面计算，误差大得离谱。建索引的时候，记得把字段类型设对，坐标必须是 [经度, 纬度] 的顺序，别反了，反了查出来的距离全是错的，那时候你就得哭爹喊娘去修正数据了。

第二步，别只用 $near。如果你只需要距离，不需要排序，用 $geoWithin 或者 $nearSphere 配合 $maxDistance 过滤范围。如果你非要排序，那就得用 $near 加上 $minDistance 和 $maxDistance 来限制范围。这样数据库就不用去算所有点的距离，只算范围内的。这一步能提升至少十倍的性能。

第三步，也是最容易被忽略的，分页。很多开发者喜欢用 skip 和 limit 来做分页，这在 geo 查询里是大忌。因为 $near 返回的结果顺序是不确定的，除非你显式指定了排序。而且 skip 在大偏移量下性能极差。我后来改成了基于上一次查询的最后一条数据的 ID 或者坐标来做游标分页，虽然代码稍微复杂点，但查询速度直接起飞。

还有个小细节，坐标的精度。如果你不需要米级别的精度，把经纬度保留少几位小数，能节省不少存储空间，也能加快索引构建速度。别为了那点精度，牺牲了性能，得不偿失。

记得有一次，我帮一个朋友调优，他的 MongoDB 实例内存才 4G，却存了两百万条位置数据。每次查询都全量加载到内存，能不卡吗？我让他把热点数据单独拎出来，冷数据归档，再优化一下索引策略，查询时间从 2 秒降到了 50 毫秒。那种成就感，真的比发工资还爽。

总之，mongodb geo距离排序 不是个技术难点，是个工程问题。别指望一个查询语句解决所有问题。你要理解数据库是怎么工作的，知道它的瓶颈在哪里。别盲目追求高并发，先保证查询的正确性和基本性能。

最后说句心里话，做技术这行，真的不能偷懒。每一个看似简单的功能背后，都是无数次的调试和优化。希望我的这些血泪教训，能帮你在踩坑的路上少摔几个跟头。要是你还遇到什么奇怪的问题，欢迎在评论区留言，咱们一起聊聊。毕竟，独乐乐不如众乐乐嘛，虽然这乐子有点苦。

本文关键词：mongodb geo距离排序