GridFS上传慢主因常是chunkSize过小：默认255KiB导致大文件切块过多、元数据开销大；应按文件类型选1–4MB（流媒体）或64–128KB（随机读写），并通过初始化参数设置，同时补全索引与分片配置。
GridFS上传慢，先确认是不是chunkSize拖了后腿
上传慢不一定是网络或磁盘问题，很可能是chunkSize设得太小，导致文件被切得过碎，产生大量小文档写入和元数据开销。MongoDB官方默认chunkSize是255 KiB（即261120字节），不是256KB——这个细微差别在计算分块数时会影响结果，比如10MB文件实际会切成40块而非39块。
关键判断点：如果上传的主要是100MB以上文件，且观察到fs.chunks集合中文档数量远超预期（例如1GB文件生成5000+ chunk文档），那chunkSize大概率偏小。
怎么改chunkSize才有效
修改只对新上传文件生效，已有文件不会自动重分块。必须在初始化GridFSBucket或GridFS实例时传入参数，不能后期动态覆盖。
- PyMongo示例：
bucket = GridFSBucket(db, chunk_size_bytes=1048576)（设为1MB） - Node.js驱动：
new GridFSBucket(db, { chunkSizeBytes: 2097152 })（设为2MB） - 注意单位：所有驱动都要求传入字节数，不是KB或MB字符串
- 不要直接改
fs.files里的chunkSize字段——这只会让后续读取失败，驱动不认
不同场景下chunkSize怎么选
没有万能值，得看你的文件类型和访问模式：
- 流媒体类（视频/音频顺序播放）：
chunkSize设1–4MB。减少HTTP请求数和MongoDB round-trip次数，连续读性能提升明显 - 高频随机读写（如CAD图纸、数据库快照）：
chunkSize控制在64–128KB。避免每次跳转都拉回几MB冗余数据 - 混合小文件（fs.files索引膨胀，查询变慢
- 绝对要避开：
chunkSize8MB。前者引发元数据爆炸，后者单次写入可能触发MongoDB内存压力告警
改完chunkSize还要做三件事
光调参数不够，容易白忙活：
- 检查
fs.chunks是否有复合索引：{ files_id: 1, n: 1 }。缺失会导致按块序号查数据变慢，上传时虽不直感，但后续下载卡顿 - 如果用了分片集群，确认
fs.chunks已按files_id哈希分片。否则大文件的所有chunk可能挤在同一个shard上，成为瓶颈 - 上传前用
upload_from_stream（PyMongo）或openUploadStream（Node.js）配合buffer控制，避免一次性把整个文件读进内存——特别是处理GB级文件时
真正影响上传速度的，往往是chunk切得太多又没配好索引，而不是MongoDB本身慢。调chunkSize只是第一步，后面两步漏掉，效果会打五折。
