gridfs默认chunksize为256kb，是在16mb bson上限与1500b mtu间折中的“够用且安全”起点；它支持约64个chunk单次批量写入，兼顾内存压力与传输稳定性。
GridFS chunkSize 默认值为什么是 256KB？
因为 256KB 是在 BSON 文档大小上限（16MB）和典型网络 MTU（1500B 左右）之间做的折中：它能塞进约 64 个完整 chunk 到单次批量写入里，又不会让单个 chunks 文档过大导致内存压力或传输中断重试成本高。这个值不是“最优”，而是“够用且安全”的起点。
你改它，不是为了“提升性能”，而是为了适配特定瓶颈——比如你的应用总在读取视频前 10 秒、或者频繁随机跳转访问日志文件的某几行。
- 默认
chunkSize: 256 * 1024（即 262144 字节）适用于小文件（ - 如果上传失败率高（尤其在弱网环境），说明单次 chunk 传输超时概率上升，应考虑下调至
128 * 1024或64 * 1024 - 如果大量顺序读（如流式播放），且后端 IOPS 充足（SSD + RAID10+），可上探到
1024 * 1024（1MB）甚至4 * 1024 * 1024（4MB），但需同步确认 MongoDB 的maxWriteBatchSize和驱动缓冲区是否撑得住
如何根据带宽判断该调大还是调小 chunkSize？
别看平均带宽，盯住「P95 上传延迟」和「单 chunk 传输耗时」。用 curl -w "@format.txt" -o /dev/null -s http://your-upload-endpoint 测真实 chunk 级上传时间，再套公式：chunkSize / 实测带宽（B/s） ≈ 理论传输时间。如果这个时间 > 你设的 socket timeout（比如 Node.js 驱动默认 30s），就危险了。
- 带宽 128 * 1024，避免单 chunk 卡死整个上传流
- 带宽 10–50MB/s（千兆内网）→
256 * 1024～1024 * 1024安全区间，优先选512 * 1024 - 带宽 > 100MB/s（RDMA/高速 NVMe 直连）→ 可试
4 * 1024 * 1024，但必须配合writeConcern: { w: "majority", j: true }避免 chunk 写入不一致
IOPS 不足时，chunkSize 调大反而更慢？
会。MongoDB 的 chunks 集合本质是大量小文档。当磁盘 IOPS 吃紧（比如 HDD 或共享云盘），写入 1000 个 256KB chunk = 1000 次随机写；而写入 250 个 1MB chunk = 250 次随机写 —— 看似省了 75% IO 次数，但每个 chunk 更大，单次刷盘更久，可能阻塞其他请求。
关键看你的存储介质和负载模型：
- HDD 或低配云盘（chunkSize 不宜 >
256 * 1024，否则写放大严重 - NVMe SSD（>10k IOPS）+ 读多写少 → 可上到
2 * 1024 * 1024，降低索引碎片和查询files集合压力 - 混合负载（同时跑分析查询+上传）→ 固定用
256 * 1024，避免 chunk 大小波动加剧锁竞争
动态调整 chunkSize 的实际限制
GridFS 的 chunkSize 是 bucket 级配置，一旦创建 bucket 就不能改。你不能让同一个 bucket 里有的文件用 128KB、有的用 4MB —— 所有文件共用一个 chunkSize。所谓“动态”，只能靠运行时路由：为不同业务路径创建多个 bucket，比如 fs-video（chunkSize: 4194304）、fs-log（chunkSize: 65536）。
- 不要试图在上传时覆盖
chunkSize参数：Node.js 驱动里openUploadStream(filename, { chunkSizeBytes: ... })会被忽略，只认 bucket 初始化时的值 - 切换 bucket 意味着要维护多套连接和权限，
bucketName必须显式传入，不能依赖默认fs - 注意监控
chunks集合的文档平均大小，用db.fs.chunks.stats().avgObjSize核对是否生效
真正难的不是算出那个数字，而是确认你的监控能捕获到 chunk 级延迟抖动、磁盘队列深度、以及驱动层 write concern 超时的真实归因——这些信号比理论带宽值重要十倍。
