Global Clusters 是需从零创建的独立部署模式，强制多区域、复合分片键（首字段须表征地理位置）、自研路由层、就近读需显式配置 readPreference=nearest，且不支持在线修改分片键。
Global Clusters 不是普通分片集群的“开关”
Atlas 的 Global Clusters 是独立部署模式，不是在已有分片集群上勾选一个选项就能启用。它强制要求你从零创建新集群，且底层架构、路由逻辑、读写行为都和传统分片不同——比如 mongos 被替换为 Atlas 自研的全局路由层，_id 字段必须带 shard key 且推荐用 location 或 region 前缀字段参与分片。
- 如果你已有生产集群，不能“升级”成 Global Cluster，只能迁移数据
- 创建时必须至少选 2 个地理区域（如
US East (N. Virginia)+EU West (Ireland)），单区域部署会报错At least two regions are required for global clusters - 默认不开启读取本地化（
readPreference=primaryPreferred仍走最近mongos），要真正就近读，得在应用连接字符串里加readPreference=nearest并配合maxStalenessSeconds
分片键设计直接决定跨区查询是否变慢
Global Clusters 对分片键极其敏感：它不支持范围查询优化，也不做跨区 scatter-gather 合并；如果查询没命中分片键前缀，请求会被广播到所有区域，延迟飙升。
- 必须用复合分片键，且首字段要是能表达地理位置的字段，比如
{ region: 1, _id: 1 }或{ country: 1, userId: 1 } - 避免用纯随机
ObjectId当唯一分片键——这会让数据均匀但彻底失去地域亲和性，查一个用户可能触发 5 个区域的 IO - 插入时若没显式指定
region，Atlas 会按客户端 IP 归属区域自动打标，但这个值不可靠，尤其在 NAT 或代理后，务必在业务层写死region字段
连接字符串里的 replicaSet 和 appName 会影响路由策略
Global Cluster 的连接字符串看起来和普通副本集一样，但 Atlas 路由层会解析 appName 和 replicaSet 参数来决定流量走向——这不是文档里明说的机制，而是实际观测到的行为。
- 去掉
replicaSet参数会导致连接失败，错误信息是Failed to connect to server at ...:27017: connection refused（其实是路由层拒绝非预期协议） -
appName如果含admin、backup等关键词，可能被路由到主区域，绕过就近原则；建议统一用业务名，如appName=myapp-user-service - 务必启用
ssl=true，Global Cluster 不接受非加密连接，否则报错SSL handshake failed
Region failover 不是自动“切流”，而是依赖 TTL 和客户端重试
Atlas 不做主动故障转移，当某个区域不可达时，它靠 DNS TTL（默认 60 秒）+ 客户端驱动的重试机制实现降级，这意味着你的应用必须配置合理的超时与重试策略。
- 默认
connectTimeoutMS=10000和socketTimeoutMS=0在跨区场景下极易卡住，建议设为connectTimeoutMS=3000、socketTimeoutMS=5000 - Node.js 驱动需启用
retryWrites=true（默认开启），但retryReads默认关闭，跨区读失败不会自动重试到其他区域，得手动捕获MongoNetworkTimeoutError后 fallback - DNS 缓存时间由 Atlas 控制，无法在客户端修改，所以区域恢复后最长可能有 60 秒“黑窗期”，期间请求仍发往宕机节点
最麻烦的不是配置多，而是分片键一旦选错，整个集群的延迟特征就定型了——改键要停服、导出、重建、再导入，没有在线变更路径。
