Zone Sharding 是 MongoDB 的手动标签分片策略，需显式设计 zone、绑定 shard 和分片键范围，并依赖应用层路由；它不自动解析地理位置，仅在查询覆盖分片键前缀时生效。
Zone Sharding 是什么，它真能按地理位置路由请求？
Zone Sharding 不是自动地理路由机制，它只是 MongoDB 提供的一种手动标签（tag）分片策略，允许你把特定 shard 和特定数据范围（通过 min/max 键范围）或文档字段值绑定。真正实现“地理位置感知”，得靠你主动设计 zone 名称、打标签、定义范围，并配合应用层路由逻辑——MongoDB 本身不解析 IP 或经纬度。
常见误判：以为开启 zone 就能自动把上海用户请求发到上海分片。实际上，除非你在写入时显式设置 location 字段（如 "region": "cn-east"），再用该字段做分片键并绑定 zone，否则数据还是随机分布的。
- 必须使用
hashed分片键以外的类型（如range或compound），因为 zone 只支持 range-based 划分 -
zone名称是任意字符串，但建议用 ISO 区域码（如"us-west"、"ap-southeast-1"）便于维护 - 一个
shard可以有多个 zone，但一个 zone 只能归属一个shard
如何为不同区域创建 zone 并绑定 shard？
操作全在 mongos 上执行，需连接到 config server 的 admin 数据库。关键命令顺序不能错：先加 zone，再给 shard 打标签，最后关联范围。
例如，让 shard0001 专存亚太数据：
sh.addShardTag("shard0001", "apac")
sh.updateZoneKeyRange("mydb.users", { "region": "apac" }, { "region": "apac" })
注意：updateZoneKeyRange 的第三个参数是闭区间上限（含），且 region 必须是分片键的一部分；如果分片键是复合键 {region: 1, _id: 1}，那范围定义也得带上 _id 边界，否则会报 Range must be based on the shard key 错误。
- zone 名称区分大小写，
"APAC"和"apac"是两个 zone - 删除 zone 范围前，必须先用
sh.removeShardTag()清除 shard 标签，否则命令静默失败 - 添加 zone 后不会触发数据迁移，需手动运行
sh.splitAt()或等待均衡器在下次平衡周期处理
为什么写了 region 字段，查询却没落在本地 shard？
最常见原因是查询没命中 zone 范围定义的分片键前缀。MongoDB 的 zone 路由只在 query 完全覆盖分片键前缀时生效。比如分片键是 {region: 1, userId: 1}，但你只查 {userId: "u123"}，那就无法利用 zone，请求会被广播到所有 shard。
- 必须保证读写都带
region条件，例如db.users.find({region: "us-west", userId: "u123"}) - 聚合管道中若含
$lookup或跨集合操作，zone 失效，可能引发远端网络拉取 - 使用
hint()强制走某个 shard 会绕过 zone，调试时容易掩盖问题 - 开启
readPreference: "nearest"对 zone 无帮助——它只影响 secondary 选择，不改变 primary 路由目标
跨区域写入冲突和延迟怎么应对？
Zone Sharding 不解决多活写入冲突。如果你在东京和法兰克福都允许写入 region: "global" 的文档，就必然面临最终一致性窗口和潜在覆盖风险。MongoDB 没有内置的冲突自动合并机制。
实际可行做法是：把 region 设计为写入约束而非仅查询优化。例如，应用层根据用户 IP 归属地，强制将 region 值设为所在 zone 名，并拒绝非本 region 的写入请求（通过预校验或数据库 validation 规则）。这样既保障数据物理就近，又避免多点更新。
- 不要用
region字段做唯一索引，否则跨 zone 写同名 region 会因索引冲突失败 - WAN 延迟会导致
majority写关注超时，建议对跨 zone 写操作降级为w:1或使用j:false - config server 本身不支持 zone，它的部署位置会影响所有 mongos 的元数据访问延迟，应尽量靠近多数 mongos 实例
真正难的不是配置 zone，而是让业务数据模型天然适配地理分区——比如用户文档带 region 很自然，但订单与用户跨 region 关联时，join 成本就藏不住了。
