本文关键词：es geo搜索原理
做Geo搜索这行十年了，见过太多人因为不懂底层原理，把Elasticsearch搞崩，或者查出来的结果南辕北辙。这篇不整虚的，直接说清楚ES geo搜索原理到底咋回事，帮你避开那些花大价钱买来的坑。
很多人以为Geo就是简单的经纬度匹配，其实大错特错。ES底层用的是Geohash或者Prefix Tree（前缀树）技术，简单说就是把二维的经纬度压缩成一串字符。这串字符越长，精度越高，但搜索速度越慢。你如果直接拿原始经纬度去搜，那简直就是灾难，服务器能直接给你干冒烟。所以理解这个原理，是优化查询的第一步。
咱们先说最常见的场景：附近的人或店。很多开发同学喜欢用distance_query，看着挺高大上，但在数据量大的时候，这玩意儿性能极差。为啥？因为它要对每个文档都计算一次球面距离，CPU直接爆满。正确的姿势是用geo_distance或者geo_bounding_box，配合索引时的预计算。记住，索引的时候把经纬度存成geo_point类型，ES会自动帮你建立倒排索引。这时候，es geo搜索原理里的核心优势就出来了：它能把空间范围快速过滤掉大部分无关数据，只留下候选集，然后再做精确计算。
再聊聊精度问题。很多人问，我的店在朝阳区，为啥搜出来到了海淀区？这通常是因为Geohash的网格划分问题。Geohash把地球分成很多小格子，相邻的格子可能物理距离很近，但字符串差异巨大。比如“wx4g0”和“wx4g1”只差最后一个字符，但实际位置可能隔了几公里。这就是为什么有时候你需要用更长的Geohash前缀，或者改用Prefix Tree。Prefix Tree把经纬度转成二进制，再分组编码，这样相邻的区域编码也相邻，搜索效率更高。当然，这也意味着索引构建会更复杂，内存占用更大。你得根据自己的数据量和查询频率来权衡。
还有个坑，就是动态映射。别信什么自动识别经纬度，一定要显式定义mapping。不然ES可能把你的经纬度当成普通数值类型，到时候做Geo查询直接报错，或者结果完全不对。定义的时候，记得加上“lat”和“lon”字段，或者直接用geo_point类型。这样ES才知道怎么帮你建索引。
最后说说实战中的优化。如果你要做实时性要求极高的附近搜索，比如外卖骑手定位，建议用Redis的Geo模块，它底层用的是ZSET，查询速度极快。但如果数据量大，需要复杂过滤，比如“朝阳区、评分4.5以上、距离5公里内”，那还是ES靠谱。这时候，es geo搜索原理里的多条件组合能力就体现出来了。你可以先过滤出朝阳区的数据，再过滤评分，最后再算距离。这样能大幅减少计算量。
别为了追求极致性能，把架构搞得太复杂。大多数业务场景，ES原生能力足够用。关键是理解数据是怎么存的，查询是怎么走的。别盲目跟风，适合自己的才是最好的。
如果你还在为Geo查询性能发愁，或者不确定自己的mapping写得对不对，欢迎随时聊聊。咱们可以一起看看你的索引结构，说不定换个思路，性能能提升好几倍。毕竟，踩过的坑多了，也就知道怎么避开了。
