gridfs读写分离在单机机械硬盘上无效，反而增加延迟；应调大chunksize至4mb、复用bucket实例、改用opendownloadstreambyname避免两次查询。
GridFS 读写分离在单机机械硬盘上根本不起作用
直接说结论：给单节点 MongoDB 配副本集、加 readPreference: "secondary"，对 GridFS 读取速度毫无帮助，反而引入额外延迟。机械硬盘本身寻道慢，驱动还要多等一次超时降级，实际更卡。
原因很实在：GridFS 的读流程本质是两步——先查 files 集合拿元数据，再按 chunks 集合的 files_id + n 顺序拉块。这两步都必须走主节点（哪怕你配了 secondary），因为 chunks 集合默认没有构建从节点索引，且多数驱动（如 Node.js 官方 driver）对 GridFS 的流式读根本不支持从节点读 chunk 数据。
常见误操作包括：
- 用
mongosh手动连 secondary 节点执行db.fs.files.findOne()看似成功，但真正调openDownloadStream()时仍打到 primary - 在 Mongoose 中全局设
readPreference: "secondary"，结果 GridFS 操作被忽略或静默 fallback 到 primary - 误以为
GridFSBucket构造时传{ readPreference: "secondary" }就能分流 —— 实际该选项只影响元数据查询，chunk 读取不受控
真正影响 GridFS 读速的关键参数只有三个
别折腾副本集读策略，先把这三件事做对：
-
chunkSizeBytes必须与机械硬盘特性匹配：4MB 是实测较优值（{ chunkSizeBytes: 4 * 1024 * 1024 }）。太小（如 256KB）导致 chunk 数暴涨，磁头反复寻道；太大（如 16MB）则小文件浪费空间，且流式读内存缓存压力陡增 - 复用
GridFSBucket实例：每次 new 会重建内部连接池和缓存，机械硬盘环境下新建实例的初始化延迟比 SSD 明显得多 - 跳过冗余元数据查询：不用
files.find().toArray()再遍历_id，改用bucket.openDownloadStreamByName("xxx")（MongoDB 4.4+），它把元数据查 + 流打开合并成一次请求，省掉一次磁盘寻道
什么时候才该考虑副本集 + GridFS 分离
仅当满足全部以下条件时，读写分离才可能带来收益：
- 部署是真实多节点副本集（至少 1 primary + 2 secondary），且 secondary 节点挂载的是独立 SSD 存储（不是同一块机械盘的软链接）
- 所有 secondary 节点的
chunks集合已手动创建复合索引：db.fs.chunks.createIndex({ files_id: 1, n: 1 })，否则查询 chunk 会全表扫描 - 应用层明确控制读路径：元数据查
files走 secondary，而chunks读仍走 primary（目前无标准 driver 支持 chunks 从 secondary 读，需自行封装流逻辑）
现实中，95% 的“GridFS 读慢”问题出在 chunkSize 不合理、频繁 new Bucket、或滥用 find() + openDownloadStream() 组合 —— 这些修好，速度提升远超加副本集。
高频小文件别硬塞 GridFS
如果业务里大量读取的是 1KB～10KB 的图标、token、配置片段，GridFS 反而是性能黑洞：
- 每个文件至少占一个 chunk（即使只用 1KB，也写满 4MB 预分配空间），机械硬盘写入即碎片化
- 读一个 2KB 文件要定位、加载、拼合至少一个 chunk，而同样数据存在普通集合里，一次
find({ _id: ... })就拿到全部内容 - GridFS 元数据文档本身比原始数据还大（含
length、uploadDate、md5等字段），IO 效率更低
这类场景，直接用普通集合存 Base64 或 BSON Binary 更快。GridFS 只适合真正的大文件：视频、日志包、导出报表（>1MB 且需分片上传/断点续传）。
