在MongoDB集群中实现地理数据局部化时，有一个关键约束必须明确：不能直接将2dsphere索引字段作为分片键。这不是操作失误，而是系统层面的硬性限制，一旦尝试就会直接报错。背后的原因并不复杂——地理空间索引的底层编码机制决定了它天生不适合用于分区路由，因为GeoHash编码产生的值分布不均匀，容易导致数据倾斜，进而引发频繁的chunk迁移。
为什么不能直接用 2dsphere 索引做分片键
MongoDB明确禁止将2dsphere索引设置为分片键，执行时会遇到Cannot use a 2dsphere index as a shard key的错误。问题出在GeoHash编码上——这种编码方式产生的值在分布上并不均匀，作为分片键很容易导致数据倾斜，某个shard上堆积大量chunk，进而引发频繁的chunk迁移风暴。正确的做法是绕开这一限制：选择一种可分片的字段（例如区域标识）作为分片键，然后配合地理空间查询和Zone机制来约束数据路由。
用 region_id 做分片键 + zones 绑定物理位置
核心思路是将地理逻辑“降维”处理：提前将地理位置映射到离散、稳定且可分片的业务区域——例如省份编码region_id: "GD"或六边形网格IDh3_id: "8928308280fffff"——然后用该字段创建哈希分片键，再为每个区域配置对应的Zone和shard。
- 先创建哈希分片键：
sh.shardCollection("db.places", { "region_id": "hashed" }) - 为每个区域添加Zone：
sh.addShardToZone("shard-gd", "GD")、sh.addShardToZone("shard-hk", "HK") - 设置Zone范围（注意是闭区间）：
sh.updateZoneKeyRange("db.places", { "region_id": "GD" }, { "region_id": "GD" }, "GD") - 确保写入文档时都携带准确的
region_id字段，否则文档可能被路由到默认shard或触发错误
地理空间查询如何不跨 shard 扫描
仅仅配置好Zone只能保证写入时数据落到正确的位置，查询时仍可能广播到所有shard——除非在查询条件中显式带上region_id。MongoDB的查询路由器（mongos）只有看到分片键的等值条件时，才会将查询下推到指定的shard。
- ❌ 错误写法（全量扫描）：
db.places.find({ location: { $near: { $geometry: { type: "Point", coordinates: [113.2, 23.1] } } } }) - ✅ 正确写法（精准路由）：
db.places.find({ region_id: "GD", location: { $near: { $geometry: { type: "Point", coordinates: [113.2, 23.1] } } } }) - 务必在
location字段上创建2dsphere索引：db.places.createIndex({ "location": "2dsphere" })，否则地理查询无法利用索引 - 如果业务允许粗略范围，可以使用
$geoWithin+$box配合region_id进一步缩小扫描范围
Zone 分布失效的三个典型信号
Zone机制平时很安静，出问题时往往没有报错，只会表现为延迟升高或负载不均。以下现象只要出现一个，就需要立即检查：
- 执行
sh.status()发现某个shard的chunk数量远高于其他shard，且对应Zone的keyRange未覆盖实际写入的region_id值 - 写入时出现
Failed to target insert: Cannot find shard for shard key，说明文档的region_id不在任何Zone范围内 mongostat显示某shard的netIn明显偏高，但该shard并未分配对应Zone——这很可能是漏配了sh.addShardToZone
需要强调的是，Zone不是自动学习的，它完全依赖你预定义的键范围和shard绑定关系。一旦地理划分发生变更（比如新增城市网格），region_id映射表和Zone配置必须同步更新，否则查询和写入都会悄悄偏离预期。
