本文关键词：elasticsearch geo查询
你是不是也遇到过这种尴尬：用户搜“附近的美食”，结果搜出来的是隔壁市甚至隔壁省的店？或者明明就在两公里外，却死活搜不到？这其实不是数据错了，而是你的elasticsearch geo查询姿势不对。今天我就把踩过的坑都掏出来，教你怎么把地理位置搜索做准、做快。
记得去年给一个本地生活平台做重构，老板急得跳脚。因为原来的搜索逻辑太简单，就是拿经纬度做范围过滤，结果用户投诉率飙升。后来我们深入研究了ES的地理索引机制，才发现问题出在精度和距离计算上。别急着改代码，先看看你是不是也犯了这几个低级错误。
第一步，检查你的字段类型。很多新手喜欢用float或者double存经纬度，这简直是灾难。ES里必须用geo_point类型。如果你还在用数值型，赶紧改。geo_point不仅能存坐标，还能自动建立倒排索引，这是实现高效范围查询的基础。我见过一个案例，把经纬度当成普通数字存，结果查询速度慢了十倍不止，CPU直接飙到100%。
第二步，理解geo_distance和geo_bounding_box的区别。这是最容易混淆的地方。bounding_box是矩形框，速度快，但会有边缘误差。比如你要搜“方圆5公里”，用矩形框可能会把对角线很远的地方也算进来。而geo_distance是圆形范围，更精准，但计算量稍大。建议混合使用：先用bounding_box快速过滤大片区域，再用geo_distance精调。我在做那个项目时，就是加了这一层过滤，查询响应时间从200ms降到了50ms以内。
第三步，注意经纬度的顺序。ES默认是lon,lat，也就是经度在前，纬度在后。这和很多地图API的习惯不一样。如果你直接传参，很可能搜出来的地点完全反了。我有个同事就栽在这上面，死活查不到数据，最后发现是把lat和lon写反了。提交文档时，一定要确认顺序。可以用对象格式{"lat": 39.9, "lon": 116.4}，这样更清晰，不容易出错。
第四步，处理距离单位。默认是米，但如果你搜的是公里，记得在查询里指定unit。比如"5 km"。不然ES会以为你要搜5米，那结果肯定空荡荡。这个细节虽然小，但极易出错。我在测试环境就经常因为漏写单位，导致查不到任何结果，排查了半天才发现是单位搞错了。
第五步，优化聚合查询。如果你要做“附近的人”或者“热门商圈”，通常会用到geo_distance_agg。这时候要注意shard的数量。如果shard太多，每个shard计算一次距离，最后再合并，性能会很差。建议根据数据量调整shard数，或者使用更高效的聚合方式。我们当时把shard数从10个降到3个，查询性能提升了30%。
其实，elasticsearch geo查询的核心就在于理解它的底层逻辑。它不是简单的数学计算，而是基于空间索引的高效检索。别把它想得太复杂，但也别掉以轻心。每一个参数，每一个类型，都可能影响最终的结果。
我见过太多人因为忽视这些细节，导致线上事故。比如有一次，因为经纬度精度不够，导致用户收到的推荐全是错的，直接影响了转化率。所以，一定要仔细测试，特别是边界情况。比如正好在边界上的点，会不会被漏掉？距离计算有没有误差？
总之，做好elasticsearch geo查询，需要耐心，也需要细心。别指望一蹴而就，多测试，多观察。当你看到查询结果精准地匹配用户需求时，那种成就感，真的无可替代。希望这篇分享能帮你避开一些常见的坑，让你的地理位置搜索更精准、更高效。
