MongoDB GridFS文件存储性能调优-MongoDB-PHP中文网

gridfs存储小文件时cpu占用异常高，因其本身未针对小文件优化，导致频繁的分块与合并操作增加cpu开销。

mongodb gridfs文件存储性能调优

GridFS 本身不优化小文件（chunkSizeBytes=255KB，导致大量元数据操作和频繁的 fs.chunks 插入/查询。尤其在高并发写入场景下，MongoDB 的 BSON 解析、分块哈希、索引更新会吃掉大量 CPU。

若文件普遍 chunkSizeBytes 调大到 512KB 或 1MB（需权衡单 chunk 内存压力）
避免用 GridFS 存纯文本或 JSON 配置——直接存 document 更快；GridFS 适合二进制流（图片、音频、PDF）
确保 fs.files._id 和 fs.chunks.files_id 上有默认索引（Driver 通常自动建，但手动检查：运行 db.fs.chunks.getIndexes() 看是否存在 { files_id: 1, n: 1 }）

不是网络慢，而是默认缓冲策略让 JVM 堆内存持续增长，尤其在未显式关闭流或未设置 maxConnectionsPerHost 时，容易触发 GC 暂停甚至 OOM。

务必用 try-with-resources 包裹 InputStream，否则 uploadFromStream() 可能持引用直到 GC
调大 GridFSBucket 的 writeConcern 级别（如 WriteConcern.MAJORITY）前先确认副本集状态，否则写入会阻塞等待多数节点确认
对 >100MB 文件，改用 openUploadStream() + 分段 write()，便于控制 buffer 大小（例如每次 write(byte[], 0, 8192)）

常见于未正确处理异步流或忽略 GridFSFindIterable 的游标生命周期。MongoDB Java Driver 不会自动读取全部 chunks，下游流关太快就会丢数据。

Codearts代码智能体

一款AI开发辅助工具，主要用于华为云Codearts平台推出的AI编码智能体，适合需要提升相关任务效率的用户。

下载

必须调用 .first() 获取单个 GridFSFile，再传给 downloadToStream()；直接对未 first() 的游标调用会静默失败
确保目标 OutputStream（如 FileOutputStream）未被提前 close()，且磁盘有足够空间——GridFS 不校验写入端容量
如果文件名含 Unicode（如中文），查询时用 Filters.eq("filename", "报告.pdf")，别用正则或模糊匹配，避免编码不一致导致查不到

GridFS 的 fs.files 和 fs.chunks 默认不自动分片，所有 chunk 都落在一个 shard 上，成为热点。一旦该 shard 负载高，find() 或 delete() 就会排队甚至 CursorNotFound 错误。

必须手动对 fs.files 按 _id 分片（推荐哈希分片：sh.shardCollection("mydb.fs.files", { "_id": "hashed" })）
fs.chunks 依赖 files_id 字段关联，所以也要按 files_id 分片（范围分片更合适：sh.shardCollection("mydb.fs.chunks", { "files_id": 1 })）
分片后禁止使用 findOneAndDelete() 删除文件——它无法跨分片原子执行，应拆成两步：先 find() 拿 _id，再分别删 fs.files 和 fs.chunks