做这行十四年了，真不是吹，我见过太多人为了搞那个地理空间搜索头发掉了一把又一把。前两天有个兄弟在群里哭诉，说他的 elasticsearch geo 搜索 怎么调都慢得像蜗牛，查个附近的人要好几秒，服务器CPU直接飙红。我一看他的mapping，差点没笑出声，这配置，不崩才怪。

咱们今天不整那些虚头巴脑的理论，就聊聊实战里那些让人头秃的事儿。很多人一上来就想着用 geo_point 类型，觉得这玩意儿全能，存经纬度方便。确实方便，但如果你数据量到了百万级千万级，还在那儿瞎用，那真是自找苦吃。

首先得说个扎心的真相：没有完美的方案，只有最适合的。你如果是做那种实时性要求极高，比如打车软件找附近司机，那 geo_point 配合 distance sorting 还能凑合。但要是你搞的是那种历史轨迹分析，或者大范围的城市级数据检索，老老实实用 geo_shape 或者分块索引可能更稳。别听网上那些大V说啥“万能索引”，那是他们数据量小，没经历过生产环境的毒打。

我见过最离谱的一个案例，有个哥们把全国所有门店的地址都塞进一个 index，然后搞了个全局的 geo 查询。结果呢？每次搜索都要扫描整个集群的 shard，那延迟，啧啧，用户体验差得想骂人。这时候你就得想想，是不是该用 geo_hash 的前缀过滤？或者干脆把数据按省份、城市分片？虽然听起来麻烦，但真能救命。

再说说那个让人又爱又恨的 distance 参数。很多人喜欢设个很大的 radius，比如 50公里，然后让 ES 去算。兄弟，你这是在给 CPU 做压力测试吗？ES 的地理计算虽然快，但也得讲基本法。如果你能结合业务场景，先通过 bbox（边界框）过滤掉明显不相关的区域，再算距离，性能能提升好几倍。这就是所谓的“先粗筛，后精算”。

还有个小细节，很多人忽略了 mapping 里的 doc_values。默认是开的，但如果你不做聚合，不做排序，只用来存数据，那其实可以关掉，能省不少磁盘空间。不过，既然你要做 geo 搜索，大概率是要排序的，所以这步慎动。

说到这儿，我得提一嘴，别迷信 ES 的自动调优。它确实聪明，但有时候太聪明了也会犯蠢。比如你的数据分布极度不均匀，有的城市数据多，有的少，那这时候默认的分片策略可能就不太合适了。你可能需要手动指定分片数，甚至用自定义的分片函数。这玩意儿有点门槛，但学会了，你就是团队里的香饽饽。

另外，别忘了监控。别等用户投诉了才去看日志。用 Kibana 搭个 dashboard，盯着 query 的耗时，盯着 shard 的数量。有时候问题不在代码，而在基础设施。比如你的 JVM 堆内存设得太小，GC 频繁，那再好的 geo 算法也跑不快。

最后想说，elasticsearch geo 搜索 这东西，水挺深。别指望看几篇博客就能精通。多测，多压测，多看看源码里的实现逻辑。当你真正理解 Lucene 是怎么处理空间数据的，你才会明白为什么有些查询快，有些慢。

总之，别怕犯错，就怕不思考。我在这一行摸爬滚打这么多年，最大的体会就是：细节决定成败，架构决定生死。希望这篇碎碎念，能帮你少走点弯路。要是觉得有点用，记得点个赞，或者在评论区聊聊你的坑，咱们一起避。

本文关键词：elasticsearch geo 搜索