分片集群中readPreference对读写分离基本无效——mongos不透传该参数给分片，所有数据读请求默认路由至各分片主节点；真正生效的读分离需在副本集层面配置标签路由或直连secondary，并确保索引与同步延迟达标。
分片集群里直接设 readPreference 对读写分离基本无效——mongos 本身不转发该参数给底层分片，所有读请求默认走各分片的主节点。
mongos 不透传 readPreference 到分片节点
客户端连接 mongos 时传 readPreference=secondary，只影响 mongos 自身元数据查询（如 config 数据库），不会改变它向 shard 发起的实际数据读请求路由逻辑。每个分片内部仍按自身副本集规则执行读偏好，而 mongos 默认不干预。
-
mongos的职责是分片键路由和结果合并，不是读策略代理 - 即使你在 connection string 里加了
readPreference=secondary，mongos查分片数据时仍用默认 primary - 验证方式：在分片节点上开启慢日志或用
db.setProfilingLevel(2)，会发现所有find操作都发生在 primary 上
真正生效的读分离必须落在分片副本集层面
读写分离的有效控制点不在 mongos，而在每个 shard 的副本集配置和客户端驱动行为。只有当分片本身是副本集，并且客户端直连该副本集（绕过 mongos）或通过 mongos + 显式标签路由时，读偏好才可能落地。
- 每个 shard 必须部署为至少三节点副本集（非单节点），否则
secondary无意义 - 给副本集成员打标签，例如
{"role": "analytics"}，并在连接时用readPreferenceTags绑定 - 连接字符串示例：
mongodb://shard1-node1:27017,shard1-node2:27017/?readPreference=secondary&readPreferenceTags=role:analytics - 注意：此方式要求应用能区分“查分片数据”和“查 config 元数据”，不能全量依赖
mongos路由
GridFS 在分片集群中无法靠 readPreference 实现读分离
GridFS 的两阶段读取（files 元数据 + chunks 数据块）在分片环境下更脆弱。即使你设了 readPreference=secondary，openDownloadStream() 内部仍会 fallback 到 primary，因为：
- 分片后的
fs.chunks表被拆到多个 shard 上，从节点不一定持有完整 chunk 分片 - 各 shard 的 secondary 节点默认没建
{ files_id: 1, n: 1 }索引，查询失败后驱动强制降级 - 同步延迟导致
files已存在但对应chunks尚未复制完成，流打开即空 - HTTP Range 请求（视频拖拽）极易因元数据与 chunk 来自不同节点而返回全量 body
生产环境唯一稳妥的读分离路径
不要指望靠一个参数开关实现分片集群读写分离。真实可用的方式是混合使用标签路由、独立连接、以及基础设施加固：
- 在所有 shard 副本集的 secondary 节点上，手动执行：
db.fs.chunks.createIndex({ files_id: 1, n: 1 }) - 聚合类批处理任务，改用直连指定 tag 的 secondary 节点（如
mongodb://node1:27017/?readPreference=secondary&readPreferenceTags=usage:report），绕过mongos - 对实时性要求低的报表查询，禁用
mongos，让应用层自己做分片键散列 + 并发查各 shard 副本集 - 绝对避免在分片集群中对 GridFS 使用
readPreference=secondary，除非你已确认每个 shard 的所有 secondary 都有完整索引且同步延迟
最常被忽略的一点：分片集群的读分离不是配置问题，而是架构取舍。一旦用了 mongos，你就放弃了对单个分片读策略的控制权；想精细调度，就得退回到副本集直连模式。
