做LBS业务这几年，最头疼的就是用户问：怎么快速查出我周围5公里的人？很多新手一上来就搞全表扫描，结果服务器直接崩盘，老板脸色铁青。这篇不整虚的，直接告诉你Geo 半径查询算法的核心门道，帮你把查询速度从秒级拉到毫秒级，彻底解决性能瓶颈。

先说个大实话，很多团队在起步阶段，为了赶进度，数据库里存经纬度，查询时直接算欧几里得距离。听着挺简单，实际上就是自杀。你想想，如果数据库里有几百万条门店数据，每次查询都遍历一遍，那CPU能给你烧红了。我见过一个案例，某本地生活平台，高峰期查询延迟高达3秒，用户直接流失率飙升20%。这就是没用好Geo 半径查询算法的下场。

那到底该怎么搞？核心就两步：过滤和精算。

第一步，别一上来就算球面距离，太慢。先用矩形框把范围圈起来。比如你要查半径5公里，那就先查一个边长10公里的正方形区域。这个正方形怎么定？很简单，以目标点为中心，向上下左右各延伸5公里。这时候，你可以利用数据库的B+树索引，快速定位到这个矩形范围内的数据。这一步能过滤掉90%以上的无效数据，剩下的才是真正需要精细计算的候选集。

第二步，对候选集进行精确的距离计算。这时候再用Haversine公式或者球面余弦定理，算出真实的大圆距离。只有小于5公里的，才返回给用户。这种“粗筛+精算”的策略，是Geo 半径查询算法的黄金标准。

但是，光靠SQL优化还不够。如果你的数据量到了千万级，甚至亿级，普通的B+树索引也会力不从心。这时候，就得请出GIS空间索引的神器了：GeoHash或者R-Tree。

GeoHash的思路很巧妙，它把二维的经纬度编码成一个字符串。距离近的点，编码前缀相似。比如“wx4g0ec1”和“wx4g0ec2”就很近。查询时，你只需要查找以“wx4g0ec”开头的所有记录，就能快速缩小范围。不过，GeoHash有个致命弱点，就是边界效应。两个点可能在物理距离上很近，但因为跨越了编码边界，导致编码差异巨大，从而被漏掉。这时候，你需要额外检查相邻的8个区块，这就增加了复杂度。

相比之下，R-Tree或者四叉树（Quadtree）在处理动态数据时表现更稳定。它们把空间递归分割成树形结构，查询时沿着树向下走，只访问相关的节点。对于高频更新的场景，比如网约车位置上报，R-Tree的插入和删除效率更高。

这里有个实战中的数据对比：在百万级数据量下，全表扫描平均耗时1.2秒；使用矩形框+B+树索引，耗时降至0.05秒；如果进一步引入GeoHash编码，并配合内存缓存，查询时间可以压缩到0.005秒以内。这中间的差距，就是用户体验的天壤之别。

最后，给几个避坑建议。第一，经纬度字段一定要建索引，别嫌麻烦。第二，半径查询时，尽量用固定半径，避免动态计算带来的性能波动。第三，如果业务允许，可以预计算一些热点区域的网格ID，直接查网格ID，速度更快。

做技术，尤其是做底层算法，不能只盯着代码看，得盯着数据看。理解数据的分布规律，选择合适的索引结构，才能事半功倍。Geo 半径查询算法不是玄学，而是数学与工程优化的完美结合。希望这篇分享，能帮你少走弯路，早点下班。

记住，好的算法不是算得最快，而是算得最准、最省资源。你在项目中遇到过哪些奇葩的查询场景？欢迎在评论区聊聊，咱们一起探讨。