做LBS应用最怕什么？不是数据量大，而是查出来的结果根本对不上号，或者干脆超时崩溃。今天这篇不整虚的，直接拿我过去9年踩过的血泪教训，教你怎么用好mongotemplate的geo查询，彻底解决定位不准、性能拉胯的头疼问题。
记得去年给一家本地生活平台做重构，老板拍着桌子说：“为什么用户离得近，推荐的全是隔壁区的店？”我一看日志，好家伙，开发者直接用经纬度做范围过滤，还加了个模糊匹配，这能快才有鬼了。这种低级错误，新手容易犯，老手有时候也会因为赶进度而忽略底层逻辑。
咱们先说最基础的地理空间索引。很多兄弟建索引时图省事，只建了2d索引，现在都2024年了，谁还用2d？必须上2dSphere。这俩的区别就像算盘和计算器，2dSphere支持球面几何计算，能准确处理地球曲率带来的误差。如果你还在用2d，赶紧改，不然在高纬度地区，误差能大到让你怀疑人生。
接下来是核心的mongotemplate的geo查询用法。这里有个大坑：很多开发者喜欢用BasicQuery去拼凑条件，看着挺灵活，但一旦涉及复杂的空间运算，代码可读性极差，还容易出Bug。我强烈建议使用Criteria API，虽然写起来稍微多几行，但逻辑清晰，维护起来省心。比如你要查“半径5公里内的商家”，代码大概长这样：
`java
GeoResults
new GeoJsonPoint(116.40, 39.90),
Store.class
).within(new Circle(5000)).all();
`
注意看，这里用的是within配合Circle，这是最标准的做法。有些朋友喜欢用near，但near返回的是距离排序，如果你不需要排序，只想要范围内的数据，within性能更好，因为它不需要计算具体距离，只需要判断是否在边界内。
再说说性能优化。有个客户的数据量达到了千万级，一开始查询耗时超过2秒，老板差点没忍住把我开了。后来我优化了索引，并且把查询条件里的非空间字段提到了前面。MongoDB的索引是B-Tree结构，空间索引虽然特殊，但也遵循这个原则。把高频过滤条件放在前面，能大幅减少扫描的数据量。另外，别在查询结果里返回所有字段，只查你需要的，比如只查_id和name，其他字段后续再按需加载。这点细节，能提升30%以上的响应速度。
还有一个容易被忽视的点：坐标系的统一。一定要用WGS84，别用GCJ02（火星坐标）。虽然国内地图大多用GCJ02，但在数据库层面，必须转回WGS84存储和查询。否则，你查出来的距离全是错的，而且错得离谱。我在处理某外卖平台数据时，就遇到过这种坑，因为前端传的是火星坐标，后端没转换，导致配送范围计算完全混乱，最后不得不重写整个模块。
最后，关于mongotemplate的geo查询的异常处理。空间查询可能会因为数据格式错误而抛出异常，比如坐标超出范围。一定要做好try-catch，并记录详细的错误日志。别让用户看到一堆乱码报错，给他们一个友好的提示：“定位失败，请检查网络或重启应用”。
总之，做好mongotemplate的geo查询，关键在于选对索引、用对API、优化查询逻辑、统一坐标系。这四步走稳了，你的LBS应用就能跑得飞快，老板也会对你刮目相看。别等出了问题再补救，现在就开始优化吧。
本文关键词：mongotemplate的geo查询
