搞定位服务、做地图应用，最怕的就是查个数据慢得像蜗牛，或者经纬度算错把人送到沟里去。你是不是也遇到过这种情况：明明代码没写错，但就是查不出附近的门店？或者一并发请求，服务器直接崩了？别急，今天咱们不整那些虚头巴脑的理论，直接聊聊 geo 数据库怎么用，才能让你的项目跑得飞快且稳如老狗。
先说个扎心的事实，很多人一开始都用 MySQL 的经纬度字段加范围查询，结果数据量一过十万，查询时间直接飙到几秒甚至超时。这时候老板催得紧，用户骂得凶，你只能熬夜重构。其实，解决这个问题的核心在于空间索引。如果你还在用普通的 B+ 树索引去搞地理空间查询，那真的就是在裸奔。
那 geo 数据库怎么用呢？第一步，选对工具。现在主流的方案主要有 MongoDB 的 GeoJSON 和 PostgreSQL 的 PostGIS。如果你用的是 MongoDB，它内置了对地理空间数据的支持，上手相对简单。你需要创建一个带有地理位置字段的集合，比如叫 "stores"，然后插入数据时，坐标必须是 GeoJSON 格式，也就是 { type: "Point", coordinates: [经度, 纬度] } 这种数组形式。注意哦，经纬度的顺序千万别搞反了，MongoDB 默认是 [经度, 纬度]，而有些其他库可能是反过来的，一旦搞反，你查出来的结果可能是南极洲而不是你家楼下便利店。
接下来就是建索引了。这是关键中的关键。在 MongoDB 里，你需要对那个地理位置字段创建 2dsphere 索引。命令大概是这样的：db.stores.createIndex( { location: "2dsphere" } )。有了这个索引，数据库才能利用球面几何算法快速定位。很多新手朋友问，geo 数据库怎么用才能最快？答案就是：索引必须建对，否则后面全是白搭。
建好索引后，就可以开始查询了。比如你想查距离某个点 5 公里内的所有店铺，可以用 $near 或者 $geoWithin 配合 $centerSphere。这里有个小坑，$near 返回的结果是按距离排序的，而 $geoWithin 只是筛选范围，不排序。如果你既要范围又要排序，记得加上 $maxDistance 参数。另外，单位要注意，$centerSphere 的单位是弧度，不是公里。你得把公里数除以地球半径（约6378公里）转换成弧度，这个计算过程容易出错，建议写个工具函数封装起来，别每次都在 SQL 里硬算，容易晕。
再说说 PostgreSQL 的 PostGIS，这个更强大，但也更复杂。它本质上是在 PostgreSQL 上加了一个扩展。你需要先启用扩展，然后创建几何列。PostGIS 支持的空间类型更多，比如 LineString、Polygon 等，适合做复杂的路径规划或区域分析。对于 geo 数据库怎么用这个问题，PostGIS 的文档非常详尽，但学习曲线比较陡峭。如果你团队里有懂 GIS 的专业人员，用 PostGIS 是明智之选；如果只是简单的附近的人、附近的店，MongoDB 可能更省心。
还有一种情况，就是数据量特别大，比如亿级数据。这时候单靠数据库可能有点吃力，可以考虑引入 Redis 的 GEO 功能。Redis GEO 基于有序集合实现，操作极其简单，add、range、distance 几个命令就能搞定。它的优势是速度极快，适合做实时性要求高的场景，比如打车软件里找附近的司机。但缺点是持久化能力弱，如果数据需要长期存储和复杂分析，还是得靠 MySQL 或 PostgreSQL。
最后，提醒几个常见的错误。第一，坐标精度问题。默认情况下，经纬度保留小数点后几位？通常保留 6 位就够了，对应米级精度。再高也没必要，反而浪费存储空间。第二，时区问题。虽然坐标本身不带时区，但关联的时间戳一定要统一，不然数据分析时会乱套。第三，边界情况。比如跨越国际日期变更线，或者在极地附近，简单的平面几何算法会失效，必须用球面算法，这也是为什么推荐用 2dsphere 索引的原因。
总之，geo 数据库怎么用，没有标准答案，只有最适合你的场景。根据你的数据量、查询频率、团队技术栈来选择。别盲目追求高大上，能解决问题、跑得快、维护简单才是硬道理。希望这篇分享能帮你少走弯路，早点下班。
