MongoDB 5.0 未优化 GridFS 性能，分块读写、chunkSize 行为、索引逻辑及删除机制均与 4.4 一致；所谓升级提效是误解，实际影响仅为更严格的参数校验和废弃 API 调整。
MongoDB 5.0 没有为 GridFS 引入专门的性能提升机制，分块读写行为与 4.4 及更早版本完全一致。 官方文档、发行说明和底层驱动变更日志中均未提及任何针对 fs.files 或 fs.chunks 的查询优化、缓存增强或 chunk 传输协议改进。所谓“升级即提效”是常见误解。
GridFS 在 5.0 中的 chunkSize 行为没变
分块大小仍由客户端（如 Node.js driver 的 GridFSBucket 构造选项、PHP 的 GridFSAdapter 配置）决定，服务端不干预也不重写该值。默认 chunkSize 仍是 256KB，计算公式 n = ceil(fileSize / chunkSize) 未调整。上传一个 100MB 文件，在 4.4 和 5.0 下生成的 chunk 数量、fs.chunks 文档结构、索引依赖关系完全相同。
- 所有 chunk 写入仍走普通
insertMany()，不受 5.0 新增的time-series collections或clustered indexes影响 -
fs.files的{ filename: 1, uploadDate: 1 }默认索引逻辑不变，膨胀问题照旧存在 - 聚合管道中
$lookup关联fs.chunks的性能表现与 4.4 无差异，仍需手动建{ files_id: 1 }索引加速
真正影响 GridFS 性能的 5.0 变更其实是副作用
某些全局性改动会间接波及 GridFS，但效果取决于你的部署方式和访问模式：
- 命令参数校验变严格：若你用自定义脚本调用
find()查询fs.chunks并误传了未声明字段（如hint: {...}），5.0 会直接报错Unrecognized field，而 4.4 会静默忽略——这可能导致旧运维脚本中断，而非提升性能 -
db.collection.ensureIndex()被彻底移除：如果你在初始化阶段用它为fs.files建复合索引，必须改为createIndex()，否则索引缺失会放大查询延迟 - 连接池行为未变，但
mongosh中mongo.setReadPref()已失效：若业务代码依赖 shell 动态切读偏好，GridFS 元数据查询可能意外落到非预期节点
别指望靠升级 5.0 解决 fs.files 膨胀
这是最常被误判的一点：5.0 没修复“删文件不删元数据”这个根本缺陷。只要还用 bucket.delete(fileId) 之外的方式清理（比如只删 fs.chunks 或只清业务表引用），fs.files 就继续堆积孤儿文档。监控时仍需执行：
db.fs.files.countDocuments({})
并与
db.fs.chunks.countDocuments({})
比对。两者差值大，说明清理逻辑没跟上——这不是版本问题，是代码契约没遵守。
真正起作用的永远是 chunkSize 选型、索引策略、删除收口和批量清理脚本，而不是 MongoDB 主版本号。5.0 只是让这些操作的边界更清晰、错误更明确，没偷偷帮你优化 IO 路径。
