secondarypreferred适用于读多写少、可容忍延迟且主节点需专注写入的场景，但并非自动分流读压力的万能方案；其真实行为是优先发请求至任意secondary，仅当所有secondary不可用时才回退至primary。
secondaryPreferred 适合读多写少、能容忍短暂数据延迟、且希望主节点专注写入的场景，但不是“自动分流读压力”的万能开关。
secondaryPreferred 的真实行为
它不会把读请求均匀分发到 secondary 节点；而是先尝试发给任意一个 secondary，只有当所有 secondary 都不可用（比如全部宕机、网络不通、或被标记为 ineligible）时，才 fallback 到 primary。这意味着：
- 如果副本集只有一个 primary + 一个 secondary，且 secondary 健康，
secondaryPreferred几乎总是走 secondary - 如果有多个 secondary，驱动会按
nearest逻辑选一个（基于 ping 时间），不是轮询或负载均衡 - 它不保证读取的数据比
primary“旧多少”，只保证不主动选 primary —— 除非别无选择
哪些场景真该用 secondaryPreferred
典型适用情况不是“想减压”，而是“读操作天然可降级”：
- 报表类查询：比如凌晨跑的每日汇总，用
secondaryPreferred避免干扰白天交易写入 - 地理就近读：应用部署在 A 地区，secondary 也在 A 地区，primary 在 B 地区，用
secondaryPreferred降低网络延迟 - 故障过渡期：primary 正在选举中不可写，但你仍希望用户能查历史订单（接受几秒延迟），这时
secondaryPreferred比primaryPreferred更早切到 secondary
容易踩的坑
很多人误以为设了 secondaryPreferred 就能“自动分担读负载”，结果发现 primary 还是 CPU 高——因为：
- secondary 节点本身也要重放 oplog，高并发读 + 复制压力可能反而拖慢同步，导致
maxStalenessSeconds触发剔除，让 secondary 被跳过 - 驱动默认不启用
localThresholdMS，如果 secondary 网络延迟略高，它可能被判定为“不可用”，请求全回退到 primary - 事务内不能用
secondaryPreferred：任何包含startTransaction()的操作，readPreference必须是primary，否则报错CommandNotSupportedOnSecondary
怎么验证它真在走 secondary
不要只看监控图，直接查日志或连接行为：
- 在 mongod 启动时加
--verbose --logLevel 1，然后 grep"received read"日志，看请求落到哪个节点 - 用
db.currentOp({secs_running: {$gt: 0}})查正在执行的 op，结合host字段确认来源 - 在客户端代码里临时加
cursor.readPref("secondaryPreferred")并打印cursor.explain().executionStats.executionStages.host（部分驱动支持）
真正起作用的从来不是参数名，而是 secondary 节点是否健康、标签是否匹配、延迟是否达标、以及你的查询有没有被事务或写关注规则强制拉回 primary。
