mongodb禁止用2dsphere索引字段作分片键，因其geohash编码导致数据分布不均、易引发倾斜和chunk迁移风暴；必须改用region_id等可分片字段配合zone机制实现地理数据局部化。
为什么不能直接用 2dsphere 索引做分片键
MongoDB 不允许将 2dsphere 索引字段直接设为分片键——这是硬性限制，尝试会报错 Cannot use a 2dsphere index as a shard key。根本原因是地理空间索引底层使用的是 GeoHash 编码，值不具备良好分布性，容易导致数据倾斜和 chunk 搬迁风暴。必须换一条路：用可分片的字段（如区域标识）做分片键，再配合地理空间查询和 Zone 来约束路由。
用 region_id 做分片键 + zones 绑定物理位置
核心思路是把地理逻辑“降维”：提前将地理位置映射到离散、稳定、可分片的业务区域（比如省编码 region_id: "GD" 或六边形网格 ID h3_id: "8928308280fffff"），然后用这个字段做哈希分片键，并为每个区域配置对应的 Zone 和 shard。
- 先创建哈希分片键：
sh.shardCollection("db.places", { "region_id": "hashed" })
sh.addShardToZone("shard-gd", "GD")、<code>sh.addShardToZone("shard-hk", "HK")
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 配置必须同步更新，否则查询和写入都会悄悄偏离预期。
