GridFS默认255KB chunk在机械硬盘上导致大量随机寻道，应调大至1MB～4MB；避免两次查询、复用bucket实例、禁用无效readPreference；小文件改用BinData，仅大而少变的文件适用GridFS。
GridFS 默认 chunk 大小在机械硬盘上太小了
MongoDB GridFS 默认把文件切分成
的 chunk，这对 SSD 影响不大，但在机械硬盘上会引发大量随机寻道——每个 chunk 都可能落在磁盘不同物理位置，读一个 10MB 文件要寻道 40+ 次，I/O 等待直接拉满。
实操建议：
把 chunkSizeBytes 提高到～
（具体看平均文件大小）：
新建 bucket 时显式指定：
已有数据无法直接改 chunk 大小，必须重新上传；别试图 patch 元数据字段
，驱动和服务器都不认
注意：增大 chunk 会略微提高内存占用（流式读取时缓存更大块），但对机械硬盘是正向权衡
避免用
查 GridFS 文件元数据再逐个
常见错误是先
拿到文档，再调
——这触发两次网络往返 + 两次磁盘寻道（一次查元数据，一次读第一个 chunk）。
更高效的做法是直接用
或
定向打开：
优先用
+
一次性拿到完整元数据，再传给
如果确定文件存在且唯一，直接
（MongoDB 4.4+），底层合并了查询和流打开逻辑
别在循环里反复 new
实例，复用同一个实例，否则连接池和缓存都浪费
对单机机械硬盘没意义，但别配错
本地单节点部署时，如果误配了
或
，驱动仍会尝试发请求、等超时、降级，徒增延迟。机械硬盘本身响应慢，这种额外等待更明显。
确认你的连接字符串或 client 配置：
单机环境统一用
（默认值，可不写）
检查是否被上层框架（如 Mongoose）或环境变量意外覆盖了
用
或日志确认实际发出的读命令是否带
参数
别让 GridFS 承担高频小文件的读负载
GridFS 不是为
的图标、token、配置片段设计的。这类文件在机械硬盘上写入时就分散，读取时更要跨多个 chunk 拼合，反而比直接存进普通集合还慢。
判断标准很简单：
文件平均
？→ 改用普通文档的
字段
需要频繁更新？→ GridFS 更新等于删+重传，机械硬盘扛不住，改用独立集合 + 版本字段
有强一致性要求（比如读刚写入的文件）？GridFS 的两阶段写（先写 chunks 再写 files）在故障时可能残留孤儿 chunk，机械硬盘故障率更高，风险放大
真正适合 GridFS 的，是那些「大、少变、顺序读多于随机读」的文件，比如日志归档、原始图片备份、视频片段——这些场景下，调大 chunk、跳过元数据二次查询、配对读偏好，才真正起作用。
255KB1MB4MBconst bucket = new GridFSBucket(db, { chunkSizeBytes: 4 * 1024 * 1024 });chunkSizefind()openDownloadStream()files.find({ filename: "xxx" })bucket.openDownloadStream(file._id)filename_idbucket.find({ filename: "xxx" }).next()openDownloadStream()bucket.openDownloadStreamByName("xxx")GridFSBucketreadPreference: "nearest"readPreference: "nearest""secondary"readPreference: "primary"readPreferencemongostatreadPreference1KB～10KB< 100KBBinData