干ES这行八年了，见过太多人栽在geo数据上。一开始觉得不就是存个经纬度嘛，随便写写就行，结果上线后查询慢得像蜗牛，甚至直接OOM（内存溢出）。今天不整那些虚头巴脑的理论，直接聊点实战里踩过的坑，特别是关于es geo数据写入这块，怎么搞才稳。

先说个真事。有个做物流的朋友，要把全国几百万个网点坐标存进ES。他图省事，用了默认的geo_point类型，直接往里灌数据。刚开始没事，跑个几千万条也还行。结果到了月底搞个“附近5公里门店”的功能，查询延迟直接飙到5秒以上，客服电话被打爆。为啥？因为默认写入时，如果没有做好映射优化，ES在倒排索引和文档存储上的开销会很大，尤其是批量写入时，内存抖动厉害。

所以，第一步，映射（Mapping）必须得设对。别用默认的，显式声明type: geo_point。这里有个细节，很多人不知道，geo_point其实支持两种格式：一种是字符串"lat,lon"，另一种是对象{"lat": 39.9, "lon": 116.4}。强烈建议用对象格式，虽然写入时稍微多打几个字符，但在后续的空间计算和聚合上，性能更稳定，解析也更高效。特别是做高频的es geo数据写入场景，对象格式能让Lucene更好地优化内存布局。

再说批量写入的性能问题。别一个个插，那是找死。用Bulk API是基本操作，但别一次塞太多。我一般建议单次Bulk请求控制在5-10MB，或者1000-2000条数据。超过这个量，ES的协调节点压力会剧增，导致GC（垃圾回收）频繁，集群直接卡顿。有个技巧，可以在写入前对数据进行分片预处理，比如按省份或城市ID分组，这样能减少跨分片的写入竞争。另外，开启refresh_interval设为-1，等批量导入完了再手动刷新，能提升30%以上的写入速度。这点在es geo数据写入优化中非常关键，别为了实时性牺牲了写入吞吐量。

还有一个容易被忽视的点：数据清洗。经纬度顺序千万别搞反了。ES要求的是lon, lat（经度在前，纬度在后），但很多前端地图库或者GPS设备返回的是lat, lon。如果在写入前不做转换，查出来的位置全是错的，而且你还找不到原因。我见过最惨的案例，把北京的数据写成了南极点附近，排查了两天才发现问题出在字段顺序上。所以，写入前务必加一层校验逻辑，确保坐标合法且顺序正确。

对于实时性要求不高的场景，比如每天更新一次的门店数据，可以用update_by_query或者定时任务批量替换。但对于实时轨迹追踪，就得用async_search或者专门的流式写入框架。这里插一句，如果数据量特别大，考虑用Logstash或者Filebeat配合ES的ingest node做预处理，把经纬度解析、格式转换都放在 ingestion 阶段完成，减轻ES主节点的负担。这也是很多大厂在做es geo数据写入时的标准姿势。

最后，别忘了监控。别等崩了才看日志。用Kibana的Index Management看看每个分片的文档数，用APM工具看看查询耗时。如果发现某个分片特别大，记得做split或者force merge。

总结一下，es geo数据写入不是简单的存个坐标，它涉及到映射设计、批量策略、数据清洗和后续查询的联动。别怕麻烦，前期多花点时间优化写入逻辑，后期能省下一半的运维精力。如果你还在为查询慢或者写入报错头疼，不妨从这几个点入手查查。实在搞不定，也可以找专业的人聊聊，毕竟有些坑，跳进去一次就够受的了。