readpreference: "secondary" 仅影响 files 集合元数据查询，opendownloadstream() 拉取 chunks 时官方驱动仍默认走 primary，因从节点缺少 {files_id: 1, n: 1} 索引，驱动自动降级导致额外延迟和失败。
GridFS 的 readPreference: "secondary" 实际只影响 files 集合查询
设置 readPreference: "secondary" 后，bucket.find() 或 bucket.findOne() 确实会把元数据（fs.files）查到从节点，但后续 openDownloadStream() 拉取 chunk 数据时，**绝大多数官方驱动（Node.js / Java / Python PyMongo）仍默认走主节点**。这是因为：fs.chunks 集合在从节点上默认没有构建索引（如 { files_id: 1, n: 1 }），驱动为避免查询失败，主动 fallback 到 primary。
- 用
mongosh连 secondary 执行db.fs.files.findOne({ filename: "x.jpg" })成功 ≠ GridFS 流式读成功 -
GridFSBucket构造时传{ readPreference: "secondary" }仅作用于元数据操作，不透传给 chunk 读取逻辑 - Mongoose 全局设
readPreference: "secondary"对 GridFS 操作基本无效，驱动内部会忽略或静默降级
为什么强制 secondary 读 GridFS 反而更慢甚至失败
在单机机械硬盘或低配副本集上，启用 readPreference: "secondary" 常导致实际读取延迟上升、偶发空流或 ChunkNotFound 错误。根本原因不是配置错，而是底层行为不匹配：
- 从节点的
fs.chunks缺少{ files_id: 1, n: 1 }复合索引 → 查询全表扫描，机械盘寻道时间爆炸 - 驱动发现从节点 chunk 查询超时或无响应 → 自动重试 + 降级到 primary，多一次网络往返
- 主从同步延迟 > 100ms 时，
fs.files已存在但对应fs.chunks尚未复制完成 → 流打开后读不到块，返回空或报错 - HTTP Range 请求（如视频拖拽）易出问题：元数据和 chunk 数据来自不同节点 → length 字段与实际块不一致 → 服务端放弃分片响应，返回 200 + 全量 body
真正能起效的读分离配置方式
GridFS 本身不原生支持读写分离，必须绕过驱动限制、手动拆解两阶段流程，并确保基础设施就绪：
- 在所有从节点上手动创建索引：
db.fs.chunks.createIndex({ files_id: 1, n: 1 }, { readPreference: "primary" }) - 元数据查询显式走从节点：
bucket.find(..., { readPreference: "secondary" })，但需配合maxTimeMS: 2000防卡死 - chunk 读取改用原生 collection 查询：
db.fs.chunks.find({ files_id: xxx, n: { $gte: a, $lte: b } }, { readPreference: "secondary" })，并自行拼接 Buffer - 连接字符串中加
&readPreference=secondaryPreferred&maxStalenessSeconds=90，让驱动在从节点不可用时自动切回主节点，避免雪崩 - 禁用自动重试：
{ retryReads: false }，否则竞态下可能第一次查 files 成功、第二次查 chunks 时主节点已切换，彻底错乱
比 readPreference 更关键的三个参数
当 GridFS 读取变慢或不准，优先检查以下三项，它们的影响远大于读偏好设置：
-
chunkSizeBytes：默认 255KB，小文件多时建议调大（如512*1024），减少 chunk 文档数量和查询次数 -
writeConcern：上传时设WriteConcern.WMajority可降低主从延迟，但会拖慢写入；若业务允许，用WriteConcern.W1换取更快同步 -
readConcern：GridFS 不支持跨集合事务，readConcern: "majority"对files+chunks组合无效，别指望它解决陈旧数据问题
真正卡住 GridFS 读速的，从来不是 readPreference 开关，而是 fs.chunks 在从节点有没有索引、主从延迟有没有压到 100ms 内、以及你是否在用 findOne() 这种高竞态接口做关键路径校验。
