## 01、痛点
周末晚上快十点，运营群里突然炸锅。用户反馈附近门店一直转圈，点进去十几秒不出列表。我是老李，后端开发。第一反应去监控平台看，果然门店接口 TP99 已经 4.8 秒，慢查询堆成山。这个接口的逻辑不复杂：根据用户手机传来的经纬度，查 5 公里内的门店，再按距离从近到远排序，同时支持品类过滤和只看营业中。当初图省事，门店数据放在 MySQL，坐标用了两个 decimal 字段。距离怎么算？应用层把符合品类的门店全拉到内存，Haversine 公式一圈，再过滤营业状态，最后排序。刚开始门店量小，一两万条还能扛；现在门店量上来了，一页附近查询要扫几十万行，索引完全使不上劲，流量一高就雪崩。

更难受的是，这类“附近”需求会越加越多。今天要 5 公里、明天要按商圈围栏、后天要看配送范围。如果继续在关系库里打补丁，SQL 会越来越复杂，维护成本直线上升。为什么现在要讲？因为 Geo 查询已经从外卖、打车、零售的加分项，变成了基础能力。与其在应用层手写公式，不如让数据库原生支持空间查询。MongoDB 天然带着这一块，而且 Spring Data 已经做好了封装，接入成本很低。

## 02、是什么
MongoDB 原生支持 GeoSpatial 查询，核心是两件事：GeoJSON 数据格式和 2dsphere 球面索引。GeoJSON 里，一个点用 `{ "type": "Point", "coordinates": [经度, 纬度] }` 表示。注意顺序不能写反：先经度，后纬度。2dsphere 索引会按球面几何建立空间索引，支持 `$near`、`$geoNear`、`$geoWithin`、`$geoIntersects` 等查询操作。比如 `$near` 可以按距离从近到远返回文档；`$geoNear` 除了排序，还能直接返回 distance 字段；`$geoWithin` 可以查某个多边形范围内的点。

Spring Data MongoDB 把这些底层命令封装成了 Java 对象。`GeoJsonPoint`、`GeoJsonPolygon`、`GeoJsonLineString` 对应 GeoJSON 几何类型；`NearQuery` 用来描述“离某个点多远”的查询；`GeoResults` 是空间查询结果包装，里面带距离信息；`@GeoSpatialIndexed` 可以在实体上声明索引。所以 Java 开发者不需要拼原生 Mongo 命令，代码可读性也高。

## 03、为什么
选型要看痛点。我们最想要的是：一次查询同时完成“空间过滤 + 业务过滤 + 距离排序”。MongoDB 的文档模型天然适配。门店就是一个文档，坐标、品类、营业状态、地址、评分都放在里面。查询时用一个 `$geoNear` 或 `NearQuery`，既按 5 公里过滤，又按距离排序，还能在 query 条件里加 `category` 和 `isOpen`。数据库层一次返回，应用层不用二次加工。

对比 MySQL，如果版本 8.0+ 可以用 `ST_Distance_Sphere`，但很多存量系统还在 5.7，或者即便能算距离，和业务索引组合也很麻烦；Redis GEO 适合简单附近查询，但业务过滤和持久化还要回源；PostGIS 功能很强，可又得另起一套空间数据库。MongoDB 的优势是：对中小团队来说，它和业务文档是一种自然的融合，不用多维护一套位置存储。2dsphere 索引也是为球面距离设计的，4000 多万平方公里上的距离误差可控。

## 04、架构
先说数据模型。一个门店文档可以是：

```json
{
  "_id": "S1001",
  "name": "某某咖啡",
  "category": "咖啡",
  "isOpen": true,
  "address": "望京街 1 号",
  "location": {
    "type": "Point",
    "coordinates": [116.481, 39.990]
  }
}
```

`location` 字段必须是 GeoJSON 规范。索引可以使用：

```js
db.store.createIndex({ "location": "2dsphere" })
```

如果组合查询很多，也可以建立复合索引：

```js
db.store.createIndex({ "location": "2dsphere", "category": 1, "isOpen": 1 })
```

这里要说明一点：MongoDB 复合索引里可以包含一个 2dsphere 和多个标量字段，但 `$geoNear` 查询不一定像普通等值查询那样完整走复合索引。实际使用中，先建单独 2dsphere，再看执行计划和慢查询决定是否调整。工程上可以用 `db.store.getIndexes()` 和 `explain("executionStats")` 验证。

整体架构不复杂：Controller 拿到 lng、lat、radiusKm、category、openOnly，交给 Service；Service 构造 `GeoJsonPoint` 和 `NearQuery`，通过 `MongoTemplate` 发起查询；Repository 负责实体映射；MongoDB 利用 2dsphere 索引返回按距离排序的结果，`GeoResults` 里直接有 `distance` 值。整个过程无外部缓存也无应用层距离计算。

## 05、实战
下面用 Spring Boot 实现“附近门店”接口。先引入依赖：

```xml
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-mongodb</artifactId>
</dependency>
```

门店实体：

```java
@Document("store")
public class Store {
    @Id
    private String id;
    private String name;
    private String category;
    private Boolean isOpen;
    private String address;

    @GeoSpatialIndexed(type = GeoSpatialIndexType.GEO_2DSPHERE)
    private GeoJsonPoint location;

    // 省略 getter/setter
}
```

`@GeoSpatialIndexed` 会在启动或首次访问时帮助创建 2dsphere 索引，但生产环境建议手动在 Mongo 侧建好。

Service 核心查询：

```java
public List<StoreVO> nearbyStores(double lng, double lat, double radiusKm,
                                 String category, Boolean openOnly) {
    GeoJsonPoint userLocation = new GeoJsonPoint(lng, lat);

    Query query = new Query();
    if (StringUtils.hasText(category)) {
        query.addCriteria(Criteria.where("category").is(category));
    }
    if (openOnly != null) {
        query.addCriteria(Criteria.where("isOpen").is(openOnly));
    }

    NearQuery nearQuery = NearQuery.near(userLocation)
            .maxDistance(radiusKm, Metrics.KILOMETERS)
            .spherical(true)
            .query(query);

    GeoResults<Store> geoResults = mongoTemplate.geoNear(nearQuery, Store.class);

    List<StoreVO> result = new ArrayList<>();
    for (GeoResult<Store> geoResult : geoResults.getContent()) {
        Store store = geoResult.getContent();
        StoreVO vo = StoreVO.from(store);
        vo.setDistanceMeters(geoResult.getDistance().getValue());
        result.add(vo);
    }
    return result;
}
```

`NearQuery.near(userLocation)` 指定用户坐标；`maxDistance(5, Metrics.KILOMETERS)` 限制 5 公里；`spherical(true)` 表明使用球面计算；最后把业务查询塞进 `query(query)`。得到 `GeoResults` 后，逐个取出门店内容和距离。`GeoResult` 的 `distance` 单位是米，因为 `Metrics.KILOMETERS` 内部会换算。

Controller 暴露接口：

```java
@RestController
@RequestMapping("/api/stores")
public class StoreController {

    @GetMapping("/near")
    public List<StoreVO> near(
            @RequestParam double lng,
            @RequestParam double lat,
            @RequestParam(defaultValue = "5") double radiusKm,
            @RequestParam(required = false) String category,
            @RequestParam(required = false) Boolean openOnly) {
        return storeService.nearbyStores(lng, lat, radiusKm, category, openOnly);
    }
}
```

调用示例：

```text
GET /api/stores/near?lng=116.481&lat=39.990&radiusKm=5&category=咖啡&openOnly=true
```

如果不想写太多 Java 封装，也可以直接用 Mongo Shell 做等价查询：

```js
db.store.find({
  location: {
    $near: {
      $geometry: { type: "Point", coordinates: [116.481, 39.990] },
      $maxDistance: 5000
    }
  },
  category: "咖啡",
  isOpen: true
})
```

但用 `$near` 拿不到实际距离值；要距离就用 `$geoNear` 聚合。Spring Data 的 `NearQuery` 实际上就是落到了这类命令上。

## 06、洞见
回到最初那个问题：只有 Point 数据是不是就够了？如果业务只做到“附近门店”，Point 确实够。但把时间拉长，你会发现空间需求会生长。比如外卖平台的配送范围，通常是一个多边形，Point 不够，得用 `Polygon`；物流轨迹是线，得用 `LineString`；多个商圈可能是 `MultiPolygon`。MongoDB 的 GeoJSON 和 2dsphere 索引并不只支持 Point，它支持这些几何类型。提前把 `location` 从两个纬经度字段升级为 GeoJSON 对象，后面扩展会平滑很多。

不过更重要的洞见不在几何类型，而在数据模型。MongoDB 真正适合“把业务 Document 与空间数据放在一个查询模型里”。门店文档的坐标、品类、营业状态、评分、配送范围都在一处，一次查询即得业务结果。相比“Redis GEO 存坐标 + MySQL 存业务”的方案，少了一层同步和应用层拼装；相比所有数据都进 PostGIS，MongoDB 的上手门槛和运维成本更低。当然也有代价：2dsphere 索引会增加写入开销，占用内存，且 `$geoNear` 在某些聚合场景下必须作为第一阶段；还有 GeoJSON 坐标顺序这个老坑。因此只能在合适的业务里用，比如门店、骑手、停车场、充电桩这类天然带经纬度的实体。

## 07、行动
把前面说的落地成三步。

第一步：检查数据格式和索引。所有门店文档的 `location` 字段必须是 GeoJSON Point，且坐标顺序正确。确认 2dsphere 索引存在：

```js
db.store.getIndexes()
```

看输出里应该有 `"2dsphere"` 索引。如果没有：

```js
db.store.createIndex({ "location": "2dsphere" })
```

第二步：实现组合查询“附近门店 + 品类过滤 + 营业状态”。在聚合查询里，`$geoNear` 需要放在第一个阶段，`query` 参数负责业务过滤，`distanceField` 输出距离：

```js
db.store.aggregate([
  {
    $geoNear: {
      near: { type: "Point", coordinates: [116.481, 39.990] },
      distanceField: "distance",
      maxDistance: 5000,
      spherical: true,
      query: { category: "咖啡", isOpen: true }
    }
  },
  { $sort: { distance: 1 } }
])
```

这条命令实际返回附近 5 公里内、咖啡品类、营业中的门店，并带距离升序。对应到 Spring Data，就是前面 `NearQuery` 那套。

第三步：检查 Geo Index 是否真的发挥作用。执行：

```js
db.store.find({
  location: { $near: { $geometry: { type: "Point", coordinates: [116.481, 39.990] }, $maxDistance: 5000 } },
  category: "咖啡",
  isOpen: true
}).explain("executionStats")
```

重点看 `winningPlan` 里是否出现 `GEO_NEAR_2DSPHERE` 或 `FETCH` 配合地理索引，以及 `executionTimeMillis` 是否在可接受范围。如果发现走了全表扫描，大概率是索引没建对或坐标顺序反了。上线前用真实业务数据压一轮，观察慢查询。

如果有更多字段过滤，也可以评估复合索引。但不要一上来就建一堆索引，`2dsphere` 本身写入成本不低，先满足核心查询，再按监控数据优化。

## 08、小结
MongoDB 的原生地理空间能力，处理“附近门店”这类需求非常顺手。它把空间条件、业务过滤、距离排序揉进一次查询，Spring Data 又提供了简洁的 Java API。实际落地时，核心就是三件事：坐标字段按 GeoJSON 存成 Point，建 2dsphere 索引，用 `$geoNear`/`NearQuery` 组合业务条件。别再在应用层手写 Haversine 了，既慢又难维护。先让数据库干它擅长的事，把精力留给业务。

## 09、链接与概念说明
- GeoJSON：RFC 7946 定义的地理数据格式。MongoDB 坐标顺序为 `[经度, 纬度]`，与部分前端库习惯不同，务必注意。
- 2dsphere：MongoDB 的球面空间索引，适合 GeoJSON 对象和球面距离计算。
- `$near`：按距离从近到远返回文档的基础空间查询。
- `$geoNear`：聚合阶段/命令，负责空间过滤、距离排序，并输出 distance 字段。
- `$geoWithin`：查询完全落在某个几何范围内的文档，如商圈围栏。
- `$geoIntersects`：判断几何形状是否相交。
- `NearQuery`：Spring Data MongoDB 对近邻查询的封装，支持 maxDistance、spherical、query。
- `GeoResult`：Spring Data 空间查询的结果包装对象，可通过 `getDistance()` 获得当前文档到目标点的距离。
- 官方文档：MongoDB GeoSpatial Query、Spring Data MongoDB Geo 章节。建议结合真实数据跑一遍 `explain`，避免凭感觉判断索引。

周末晚上快十点，运营群里突然炸锅。用户反馈附近门店一直转圈，点进去十几秒不出列表。我是老李，后端开发。第一反应去监控平台看，果然门店接口 TP99 已经 4.8 秒，慢查询堆成山。这个接口的逻辑不复杂：根据用户手机传来的经纬度，查 5 公里内的门店，再按距离从近到远排序，同时支持品类过滤和只看营业中。当初图省事，门店数据放在 MySQL，坐标用了两个 decimal 字段。距离怎么算？应用层把符合品类的门店全拉到内存，Haversine 公式一圈，再过滤营业状态，最后排序。刚开始门店量小，一两万条还能扛；现在门店量上来了，一页附近查询要扫几十万行，索引完全使不上劲，流量一高就雪崩。

《Spring Mongo实战》第17招 Geo做附近门店

用 MongoDB 原生地理空间查询和 Spring Data 封装，5 分钟内实现附近门店、品类过滤、营业状态组合查询，并检查 2dsphere 索引。

架构师

数据库

后端

开发工具

MongoDB原生地理空间查询实战：解决门店附近搜索性能瓶颈，通过GeoJSON+2dsphere索引实现高效空间过滤与距离排序，SpringData封装简化Java开发，一次查询完成业务过滤与距离计算，支持Point、Polygon等几何类型，替代应用层Haversine公式，提升系统响应速度。

代码解释

MongoDB

MySQL

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Spring Mongo实战》第17招 Geo做附近门店-腾讯云开发者社区-腾讯云

《Spring Mongo实战》第17招 Geo做附近门店

《Spring Mongo实战》第17招 Geo做附近门店

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐