MongoDB 4.0 不支持跨分片的全局快照读，readConcern: "snapshot" 仅在副本集事务中有效，分片集群中会被拒绝或降级为 "local"；其根本原因是各 shard 的 oplog 不同步，无法构建统一时间点视图。
MongoDB 4.0 不支持跨分片的全局快照读（Snapshot Read）。所谓“跨分片 Snapshot Read”在 4.0 版本中根本不存在，这是常见误解的源头。
为什么 readConcern: "snapshot" 在分片集群中不生效
该读关注级别仅在副本集（replica set）中受支持，且必须配合事务使用；在分片集群中，readConcern: "snapshot" 会被 mongos 拒绝或静默降级为 "local" —— 官方文档明确标注其“not supported on sharded clusters”。原因在于：snapshot 依赖 WiredTiger 的底层 snapshot 机制与 oplog 时间戳对齐，而分片集群中各 shard 的 oplog 并不同步，无法构造统一时间点视图。
- 执行
db.runCommand({find: "coll", readConcern: {level: "snapshot"}})会直接报错ReadConcernNotSupportedOnShardedCluster - 即使在事务中设了
readConcern: "snapshot"，若事务涉及多个分片，mongos 会在协调阶段拒绝启动，返回TransactionNotSupportedOnShardedCollection或类似错误 - 真正能用
"snapshot"的场景，仅限于：单副本集 + 单数据库 + 多集合（非跨库、非分片）
分片集群中唯一可行的“类快照”读方案是 readConcern: "majority"
它不是快照，而是“多数已确认”视图。在单个分片内部可防止读到回滚数据，但跨分片仍无全局一致性保障：
- shard A 返回了写入后的新值，shard B 还在同步中，你同时查两者就会看到不一致状态
- 必须搭配
writeConcern: {w: "majority"}才有意义；否则 majority 读只是空谈 - 若分片节点数为偶数（如 4 节点），未配置仲裁节点（arbiter），可能因无法形成多数派导致
ReadConcernMajorityNotAvailableYet错误 - 驱动需 v3.6+（Node.js driver ≥ 3.6.0），旧版会忽略该设置并静默回退
跨分片强一致读的现实路径只有两个
要么接受最终一致，要么把一致性成本显性化：
- 用分布式事务（4.2+ 支持跨分片事务），但所有操作必须落在同一分片上 —— 即所有集合需有相同分片键，且
sh.enableSharding()已启用，否则事务启动即失败 - 放弃数据库层强一致，改用应用层补偿：例如先查 shard A 的订单状态，再通过消息队列触发 shard B 的库存校验，超时未响应则标记为 inconsistent 并人工介入
- 最常被忽略的一点：很多所谓“跨分片不一致”问题，其实源于数据建模不当 —— 把本该内嵌的地址、明细强行拆到另一分片的集合里，结果不得不靠事务兜底
真正难的不是配置参数，而是判断“这个业务场景是否真的需要跨分片实时一致”。多数时候，答案是否定的。
