本文关键词：es geo使用场景
搞定位、找附近的人、算配送范围，这些事儿你是不是头大？这篇不整虚的，直接教你怎么在 Elasticsearch 里玩转地理空间查询，解决你业务里那些让人头疼的坐标难题。
咱说实话，很多刚接触 ES 的朋友，一听到“地理空间”就觉得高大上，其实剥开那层皮，就是简单的数学题加索引优化。我见过太多团队，为了做个“附近5公里商家”的功能，把数据库查崩了，或者 ES 查询慢得像蜗牛。为啥？因为没搞对 es geo使用场景 的核心逻辑。
第一步，建索引的时候，字段类型千万别选错。必须是 geo_point。别偷懒用 double 存经纬度，那样查起来能累死你。比如我在做一个外卖平台的 Demo 时，直接定义了 location 字段为 geo_point。这时候要注意，经纬度的顺序，ES 默认是 [lon, lat]，也就是先经度后纬度。你要是按 [lat, lon] 传数据，那查出来的结果能把你气笑，北京的位置可能跑到非洲去了。这点坑，我当初踩得那叫一个深，数据对不上，查日志查到眼瞎。
第二步，数据写入要讲究。别一股脑全扔进去。对于高频查询的场景，比如实时查找附近的快递员，你得考虑性能。我有个朋友做的物流追踪系统，初期没做分片优化，查询延迟高达 2 秒。后来他调整了 mapping，并且使用了 geo_shape 来处理多边形区域，比如某个城市的行政边界。这时候，es geo使用场景 的优势就出来了，你可以直接查询“位于朝阳区内的所有订单”。
第三步，查询语句怎么写？别死记硬背。最常用的是 geo_distance。比如你要找离我当前位置 10 公里内的咖啡馆。代码大概长这样：
{
"query": {
"geo_distance": {
"distance": "10km",
"location": {
"lat": 39.9042,
"lon": 116.4074
}
}
}
}
这里有个细节，distance 单位可以是 m, km, mi 等，别写错了单位，不然查出来的范围离谱得让你怀疑人生。
第四步，也是最重要的一点，别忽视 geo_bounding_box。如果你做的是地图选点，比如用户拖动地图框选一个矩形区域，这时候用 geo_bounding_box 效率最高。它比 geo_distance 快得多，因为它不需要计算球面距离，只是简单的矩形交集判断。我在处理一个大型活动签到系统时，高峰期每秒几千次查询，用 geo_bounding_box 把响应时间压到了 50 毫秒以内。这才是真正的实战经验。
第五步，聚合查询。有时候你不仅想知道有哪些点，还想知道这些点的分布情况。比如统计每个区域的订单密度。这时候用 geo_hash_grid 聚合。它能把经纬度编码成网格，相同网格的点归为一类。这招在热力图展示上特别好用。不过要注意，层级太深会导致内存溢出，一般设个 7 到 9 层就够了，别贪多。
最后，得说点实在的。ES 的地理查询虽然强大，但不是万能的。如果你的数据量达到亿级，且查询极其频繁，建议结合 Redis 的 Geo 功能做缓存，或者用专门的 GIS 数据库。ES 更适合做近实时的分析和复杂的空间过滤。别把 ES 当成万能钥匙，用对地方才是关键。
总之，玩转 es geo使用场景 ，核心就三点：字段类型要对，查询语句要准，性能优化要到位。别被那些复杂的术语吓住，动手试试，你就明白了。记住，数据不会骗人，但错误的配置会。希望这些经验能帮你少走弯路，早点下班。
