做搜索这行十三年了，真没见过几个不踩Geo坑的。以前用Solr的时候，我就觉得这玩意儿配置复杂，现在转到Elasticsearch，虽然文档写得好，但真上手了，还是能把你折磨得怀疑人生。今天不整那些虚头巴脑的理论，就聊聊怎么把elasticsearch geo 索引 玩明白，特别是那些让你半夜惊醒的Bug。

很多新人一上来就想着搞什么“附近的人”，结果数据一导入，查询半天不出结果，或者查出来的距离差之千里。我见过最惨的一个案例，某外卖平台，因为坐标精度没设对，导致骑手定位偏差两公里，用户投诉炸了锅。其实问题出在细节上。

第一步，建索引mapping的时候，别偷懒用默认类型。一定要显式指定为geo_point。有些老哥喜欢用object或者nested去套，那是给自己找罪受。geo_point支持多种格式，我推荐用lat/lng对象，或者geo_shape，但大多数场景下，lat/lng就够了。记住，经纬度顺序千万别搞反了，Elasticsearch默认是lat,lng，也就是先纬度后经度，这跟GPS设备输出可能不一样，很多人就在这栽跟头。

第二步，数据清洗。这一步至关重要。你从数据库导出来的数据，要是带空值，或者格式不对，直接报错。我在处理一个物流轨迹数据时，发现有些旧数据经纬度是字符串类型的，比如"116.40,39.90"，这种直接导入会失败。得先写个脚本，把它们转成数字，或者转成标准的geo_point格式。别嫌麻烦，这一步省了，后面查询全废。

第三步，查询姿势要帅。别用match_query去查地理位置，那是文本匹配。要用geo_distance或者geo_bounding_box。比如查“方圆5公里内的店铺”，geo_distance是最常用的。这里有个坑，就是距离单位。默认是米，但如果你数据量大，查询慢，可以考虑用geo_shape做预过滤，或者用更高效的聚合方式。我有个客户，之前用geo_distance查百万级数据，响应时间要3秒，后来加了个geo_shape的预过滤，降到了200毫秒。

第四步，优化性能。如果数据量特别大，比如上亿条，每次查询都全表扫描肯定不行。这时候得考虑分片策略。别把所有geo数据都塞到一个分片里，那样查询会卡死。根据业务场景，按城市或者区域分片，或者用索引生命周期管理，把冷数据归档。另外，别在查询时返回所有字段，只查需要的，比如只返回店铺名称和距离，别把详情全吐出来，网络IO也是瓶颈。

第五步，测试验证。上线前，一定要用真实数据做压测。别拿几条样例数据就跑生产环境。我见过太多人，测试环境没问题，一上线就崩。特别是高并发场景，geo查询对CPU和内存消耗不小。记得监控JVM堆内存，别让GC频繁触发。

最后，总结一下。elasticsearch geo 索引 虽然强大，但细节决定成败。从mapping设计到数据清洗，再到查询优化，每一步都得细心。别指望一次成功，多试错，多记录。我当年也是踩了无数坑，才总结出这些经验。希望这些能帮到你，少走弯路。

本文关键词：elasticsearch geo 索引