机械硬盘上GridFS读取慢的根本原因是255KB默认chunk导致大量随机寻道，应将chunkSizeBytes调至4MB以减少寻道次数、提升顺序IO比例，并复用bucket实例、使用openDownloadStreamByName避免两次查询，小文件改用BinData存储。
机械硬盘寻道延迟是GridFS读取的硬瓶颈
GridFS在机械硬盘上慢，根本不是数据库配置问题，而是物理特性卡死——每个chunk都可能落在磁盘不同扇区，255KB默认分块会让10MB文件触发40+次寻道。SSD上不明显，但机械盘上这一步就吃掉80%以上I/O时间。
实操建议：
- 别指望
readPreference: "secondary"能分流：副本集从节点若挂载同一块机械盘，实际仍是串行寻道，还多一次网络转发和超时降级 - 确认磁盘是否真为独立设备：用
lsblk和cat /proc/mounts核对secondary节点的/var/lib/mongodb是否指向不同物理盘（而非LVM或软链接） - 监控真实寻道压力：
iostat -x 1中重点关注%util和await，若await > 20ms且%util ≈ 100%，说明已到机械盘极限
chunkSizeBytes必须匹配磁盘吞吐特性
默认255KB对机械盘是反模式：太小→碎片化寻道；太大→小文件浪费空间、流式读内存压力陡增。实测4MB在平均文件≥2MB场景下最平衡。
注意点：
- 新建
GridFSBucket必须显式传参：new GridFSBucket(db, { chunkSizeBytes: 4 * 1024 * 1024 }) - 已有数据无法在线修改
chunkSize：改files.chunkSize字段无效，驱动和服务器都不识别，必须重传 - chunkSize影响缓存效率：4MB chunk让单次读更接近顺序IO，提升OS page cache复用率，而255KB chunk反复换页，
unmodified pages evicted指标会异常高
WiredTiger缓存对GridFS读写几乎无直接作用
cacheSizeGB调再大，也缓存不了fs.chunks的BinData流——WiredTiger只管B-tree页面（索引、小文档），GridFS chunk是逐个查询+解包的直通路径，绕过page cache。
验证方式：
- 执行
db.runCommand({serverStatus: 1}).wiredTiger.cache，观察bytes currently in the cache在GridFS高并发读时是否明显增长（通常不涨） - 真正该盯的指标是
tracked dirty bytes in the cache（脏页积压）和pages evicted by age（老化淘汰过快），它们反映的是元数据和索引缓存健康度，而非文件流 - 机械盘场景下，OS文件系统缓存比WT缓存更重要：留足16GB+给OS缓存journal和mmap文件页，比盲目调大
cacheSizeGB有效得多
CPU核心数与并发事务槽位强相关
GridFS写入瓶颈常卡在concurrentTransactions.write：每上传一个文件都要开事务写fs.files + 批量insert fs.chunks，默认128槽位在32核机器上跑满后，后续请求排队等待。
关键动作：
- 检查当前槽位使用率：
db.serverStatus().metrics.transactions.currentActive持续接近128即为瓶颈 - 调整需同步改三项：
storage.wiredTiger.engineConfig.cacheSizeGB（留OS内存）、storage.wiredTiger.collectionConfig.blockCompressor: "zstd"（减小写入体积）、storage.wiredTiger.engineConfig.journalCompressor: "zlib"（压缩日志I/O） - 注意：MongoDB 6.0+才支持zstd，旧版本用snappy，journal只支持zlib或none
机械硬盘上GridFS的性能拐点不在参数调优，而在是否接受“它本就不适合高频小文件”这个事实——BinData存图标、token，GridFS只留给2MB以上、低频更新的大文件，否则所有优化都是在对抗物理定律。
