MongoDB 地理位置查询，别把距离计算全丢给应用层

带坐标的数据一多，最常见的需求之一就是“按距离最近排序”。
很多人一开始会先把经纬度查出来，再在应用层自己算距离、自己排序。小数据量时确实能跑，但 2016 年我在看这类场景时越来越觉得，所有距离计算都堆在应用层，其实是在主动放弃数据库已经能帮你做的一部分工作。

应用层全算为什么会越来越吃力

因为它天然意味着：

• 先拉一批候选数据到服务端
• 再逐条做距离计算
• 最后在内存里排序和截断

数据一旦上来，CPU 和内存压力都会转到应用层，而且网络传输也会跟着变重。

数据库层的价值不只是“能算”

MongoDB 做地理位置查询时更有价值的一点，是它能在靠近数据的地方先帮你做筛选。
也就是说，很多时候你不需要先把所有候选点捞出来，再自己决定谁更近，而是可以让数据库先把不可能命中的部分压掉。

这不仅是性能问题，也是系统边界问题：该在数据层完成的粗筛，就别一股脑搬到应用层。

我后来更喜欢的思路

我会把职责拆成两段：

• 数据库层做地理相关的基础筛选和排序
• 应用层再补业务规则，比如营业状态、内容可见性、额外过滤

这样两边都做自己更擅长的事，整体会稳很多。

小结

MongoDB 地理位置查询最容易犯的错，就是觉得“距离公式我会写，所以都放应用层也没事”。
真正到线上数据量和请求量起来后，这种做法很快就会变得笨重。2016 年之后我对这类查询的态度越来越明确：数据库层能力该用的时候就要用，不然应用层只是在替它背不必要的压力。