做LBS应用最头疼的往往不是业务逻辑，而是底层怎么存坐标、怎么查得快。这篇文章直接告诉你怎么用好elasticsearch geo 索引，解决定位不准、查询慢、数据乱这三个核心痛点。看完这篇，你就不用再对着满屏的报错日志发呆了。
记得刚接手那个外卖配送项目时，团队里没人懂ES的空间查询。
当时为了赶进度，大家随手把经纬度存成了两个普通的double字段。
结果呢？每次查“附近5公里”都要全表扫描，服务器CPU直接飙到90%。
那种感觉，就像是用菜刀去砍大树，累死人还不出活。
后来我们重构了索引，才真正体会到geo_point类型的威力。
首先，建索引的时候千万别偷懒。
很多人喜欢把经纬度分开存，或者存成字符串，这都是大忌。
必须使用geo_point类型，这是ES专门为地理位置设计的。
在建mapping的时候，记得加上ignore_malformed参数。
这能防止脏数据导致整个索引挂掉，生产环境里脏数据比你想的要多得多。
比如我们之前遇到过某些GPS漂移产生的异常坐标，如果不忽略，整个分片都会报错。
数据导入阶段也是个坑。
我们当时从MySQL同步数据，发现有些商家地址解析出来的经纬度是空的。
这时候不要直接跳过，最好做个默认值或者标记为无效。
否则查询的时候，这些空值会干扰距离计算，导致结果莫名其妙。
关于查询，最常用的就是geo_distance和geo_bounding_box。
geo_distance适合查“附近的人”，比如餐厅、加油站。
但要注意，距离计算是基于球面的，不是平面几何。
如果你把地球当成平面算，误差会越来越大。
特别是跨越赤道或者经度180度的时候，误差能到几公里。
我们有一次上线后，发现南方用户收到的推荐列表偏北了大概3公里。
排查半天才发现是坐标系没对齐，一个是WGS84，一个是GCJ02。
这个坑踩得挺疼的，建议大家统一用WGS84，或者在入库前做一次转换。
还有一个容易被忽视的点，就是索引的性能优化。
geo索引默认是倒排索引，查询快但写入慢。
如果你的数据量特别大，比如千万级的签到记录，建议开启doc_values。
这样虽然占点磁盘空间，但聚合查询和排序会快很多。
我们当时把doc_values关掉，做聚合统计的时候，查询时间从200毫秒变成了2秒。
用户反馈说App卡得像PPT，老板差点没把我们全开了。
另外，geo_shape类型也别乱用。
除非你要查多边形区域，比如“北京市朝阳区”这种范围。
否则纯点查询，geo_point就够了。
geo_shape的维护成本高，查询逻辑也复杂，容易把自己绕晕。
最后说个细节，分页查询的时候要注意from/size的限制。
geo查询不支持深度分页，超过1万条数据就要用search_after。
不然内存溢出是迟早的事。
我们当时没注意这个，测试环境没问题，一上生产就OOM。
重启服务后，日志里全是堆栈溢出错误，吓得我半夜爬起来改代码。
总之，用好elasticsearch geo 索引，关键在于规范数据、选对类型、注意性能。
别指望它能自动帮你解决所有问题，细节决定成败。
希望这些踩坑经验能帮你少走弯路。
毕竟，早点下班才是正经事。
如果你们也在用elasticsearch geo 索引，欢迎评论区聊聊你们遇到的奇葩问题。
大家一起避坑，总比一个人踩雷强。
记住，技术是为业务服务的，别为了炫技把简单问题复杂化。
清晰、稳定、高效，才是好系统的标准。
好了，今天就聊到这，我去喝杯咖啡压压惊。
希望这篇关于elasticsearch geo 索引的文章能帮到你。
祝你的项目上线顺利，不再背锅。
