分片集群中读偏好需两级配置：mongos选路由由localThresholdMS决定，分片内节点选路由推荐nearest模式，secondary易导致错误路由，事务内强制primary且不可覆盖。
分片集群中直接套用副本集的 readPreference 配置，大概率导致读请求被错误路由到远端 mongos 或过时节点——这不是配置错了，而是没意识到分片层和副本集层的读路由是两级决策。
mongos 实例间的选择：localThresholdMS 决定“就近”范围
当连接字符串里指定多个 mongos（如 mongodb://s1:27017,s2:27017,s3:27017），驱动不会轮询或负载均衡，而是先测所有 mongos 的平均往返时间（RTT），选最快的那一个作为“最近”，再以它为基准 + localThresholdMS（默认 15ms）划出延迟窗口，把落在窗口内的 mongos 加入候选池，最后随机挑一个发起请求。
- 如果业务跨地域（比如上海、新加坡、法兰克福都有应用节点），
localThresholdMS设太大（如 100ms）会让新加坡节点也“挤进”上海应用的候选池，反而增加跨洋延迟 -
localThresholdMS必须在连接字符串里显式设置，SDK 层无法运行时动态覆盖；例如：mongodb://s1:27017,s2:27017/?localThresholdMS=5 - 不建议依赖 DNS 轮询或多地址连接做“软负载”，因为驱动只选一个
mongos用到底，除非该mongos连接失败才会重选
分片内副本集节点的选择：nearest 模式才是分片场景的合理起点
在分片集群中，secondary 或 primaryPreferred 这类基于角色的读偏好意义被大幅削弱——因为 mongos 本身不存数据，它只是把请求转发给对应分片的副本集。真正决定读哪个物理节点的，是每个分片内部的服务器选择逻辑。
- 对分片集群，
nearest是最贴近实际需求的模式：它同时考虑主/从节点的 RTT，且天然兼容maxStalenessSeconds和标签集，避免因某一分片主节点网络抖动而整体降级 -
secondary在分片下容易误伤：假设某分片只有 1 个从节点在线，其他都宕了，secondary会强制读它；而nearest会因无合格从节点自动 fallback 到主节点，可用性更高 - 标签集（
tagSet）必须配合nearest或secondaryPreferred使用才生效；单独配primary时传tagSet会被静默忽略
对冲读（Hedged Reads）启用条件与真实收益
对冲读不是“并发发多个请求取最快响应”，而是 mongos 向同一分片的多个副本集成员并发发送读请求，收到第一个有效响应即返回，其余请求被主动取消。但它有硬性前提：
- 仅对非
primary读偏好生效（nearest、secondary等），且需显式开启：{ hedged: { enabled: true } } - 必须确保所有
mongos实例已启用对冲支持（MongoDB 4.4+ 默认开启，但旧版或定制部署可能关闭） - 实测显示：在跨机房高延迟场景（如 RTT > 30ms），对冲读可降低 P95 延迟 20%~40%；但在同机房局域网内，开销反超收益，甚至因取消请求增加
mongosCPU 压力
事务内读偏好不可覆盖，primary 是唯一合法值
任何包含读操作的 ACID 事务，无论你如何设置客户端或集合级的 readPreference，驱动都会强制使用 primary，且不允许传 tagSet 或 maxStalenessSeconds。
- 这是协议级限制：事务要求所有操作路由到同一节点，而副本集只有主节点能保证写入顺序和因果一致性
- 如果你在事务中调用
cursor.readPref('nearest')，它会被静默忽略；db.runCommand()更彻底——从 mongosh 2.0 起，它完全不继承任何全局读偏好，必须用options.readPreference显式传参 - 想绕过？不行。试图用
primaryPreferred或secondary启动事务，驱动会在执行第一条读操作时报错：Transaction numbers require a primary read preference
最易被忽略的一点：分片集群的读偏好生效位置不在应用到 mongos 的链路，而是在 mongos 转发到具体分片副本集的那一刻。这意味着你调优的重点，不是让应用连得“更聪明”，而是确保每个分片内部的节点拓扑、网络延迟、标签分布都真实支撑你声明的偏好——否则所有配置只是纸上谈兵。
