做搜索开发的兄弟，碰到地理位置查询这块儿，心里是不是总有点发虚？
别慌，这事儿真没你想的那么玄乎。
我见过太多人，一上来就搞什么复杂的经纬度算法，结果查出来的数据乱七八糟，用户骂娘，老板拍桌子。
其实，Elasticsearch 早就把这块儿给安排得明明白白了。
今天咱就掏心窝子聊聊，怎么用最地道的方式，搞定 es geo查询。
先说个真事儿。
前阵子有个做同城生活服务的客户，找我救火。
他们的APP有个“附近的人”功能，延迟高得离谱，有时候转圈圈能转半分钟。
我一看日志，好家伙，全表扫描，还在那儿算直线距离。
这哪是搜索啊，这是在给服务器做压力测试呢。
后来我让他们上了 geo_point 类型，配合 es geo查询 的 distance 功能，那速度，嗖的一下，毫秒级响应。
用户爽了，服务器也凉快了。
所以啊，工具选对，事半功倍。
那具体咋弄呢？
咱别整那些虚头巴脑的理论，直接上干货。
第一步，建索引的时候，字段类型得选对。
千万别用 text 或者 keyword，那是给人看的，不是给机器算距离的。
得用 geo_point。
在建映射的时候，记得把 location 字段标为 geo_point。
这就好比给数据发了个身份证，告诉 Elasticsearch：“嘿，这玩意儿是地理位置，你得按地理的规则来管它。”
第二步，存数据的时候，格式得规范。
一般有两种写法。
一种是数组形式，比如 [经度, 纬度]。
另一种是对象形式，比如 {"lon": 116.4, "lat": 39.9}。
我推荐用对象形式，看着清晰，不容易出错。
注意啊，经度和纬度别搞反了。
很多新手就在这儿栽跟头，查出来的结果在地球另一头，尴尬不？
第三步，写查询语句。
这里就要用到 es geo查询 的核心了。
用 geo_distance 或者 geo_bounding_box。
如果你是想查“方圆5公里内”，那就用 geo_distance。
参数里写上 origin，也就是中心点的经纬度，再写上 distance，比如 "5km"。
简单粗暴，效果拔群。
要是想查“某个矩形区域”，比如一个商圈，那就用 geo_bounding_box。
左上角和右下角的坐标一给，框住范围，齐活。
这里有个小窍门。
如果你查的范围特别大，比如全国范围，建议先分片，再查。
不然全集群扫一遍，CPU 能给你干冒烟。
第四步，优化性能。
这点很多人忽视。
geo_point 查询默认是精确匹配，但如果你只是大概范围，可以用 geo_shape 或者 pre_filter。
另外，别在查询条件里加太多无关字段。
只查需要的，返回需要的。
数据量大的时候，分页也要小心。
深分页是个坑，跳着查容易超时。
实在不行，用 search_after，虽然麻烦点，但稳当。
我有个朋友，之前做外卖配送范围查询，也是这么折腾过来的。
一开始用 MySQL 的经纬度函数，查个周边店铺，慢得像蜗牛。
后来迁移到 ES，用了 es geo查询 的 geo_distance 功能，配合空间索引，查询速度提升了十几倍。
老板当时那个高兴啊，直接给团队发了红包。
所以说，技术这东西，关键是用对地方。
别为了用而用，得看场景。
如果是简单的坐标存储，也许关系型数据库就够了。
但要是涉及复杂的地理空间分析，比如附近推荐、热力图、路径规划，那 ES 绝对是你的最佳拍档。
最后再啰嗦一句。
调试的时候，多用 _explain 看看查询是怎么执行的。
看看是不是命中了索引，是不是走了正确的路径。
别闭着眼睛写代码，那样只会离成功越来越远。
总之，es geo查询 不难，难的是你愿不愿意沉下心来，把细节抠清楚。
只要步骤对了，数据准了，速度快了，你的产品自然就有竞争力。
别犹豫了，赶紧去试试吧。
哪怕只是小范围测试，也能让你感受到那种丝滑般的流畅感。
记住，代码是写给人看的，但性能是机器说了算。
只有机器跑得快，用户才会觉得你牛。
好了，今天就聊到这。
有啥不懂的，多翻翻官方文档，多试几次，自然就通了。
加油，打工人！
