单纯增加服务器物理内存对GridFS读取缓存命中率几乎没用——WiredTiger的cacheSizeGB不缓存GridFS chunk流，真正影响命中率的是HTTP层缓存策略、chunkSize设置及Nginx磁盘缓存配置。
单纯增加服务器物理内存，对 GridFS 读取缓存命中率几乎没用——WiredTiger 的 cacheSizeGB 只缓存索引和小文档热数据，不缓存 GridFS 的 chunk 流；机械硬盘上大文件读取压根不走这块缓存。
GridFS 文件读取根本不经过 WiredTiger 缓存层
WiredTiger 缓存管理的是 B-tree 页面（索引、_id、小文档），而 GridFS 的 chunk 是以 BSON BinData 形式存储在 chunks 集合里，驱动调用 openDownloadStream() 时是直接按 chunk 序号逐个查询 + 流式解包，绕过了 WT 的 page cache。即使你把 cacheSizeGB 设到 32GB，10MB 图片的 40 个 chunk 依然每次都要从磁盘读取。
- 验证方式：查
db.serverStatus().wiredTiger.cache["bytes currently in the cache"]，高并发 GridFS 下该值基本不涨 - 典型现象：
mongostat显示netIn/netOut高，但page相关指标（如pages evicted）无明显变化 - 误区根源：误把“数据库整体缓存”等同于“文件流缓存”，二者在 MongoDB 架构里完全隔离
真正影响 GridFS 命中率的是 HTTP 层缓存策略
GridFS 本身不发 HTTP 响应头，cache-control、etag 全靠你在应用层或反向代理层补全。客户端（浏览器、APP）是否复用本地副本，只看这些头字段，跟 MongoDB 内存毫无关系。
- 必须用文件唯一标识生成缓存键：
md5(file_content)或自定义_id，别用filename（可能重复或被篡改） - Nginx 示例（关键配置）：
proxy_cache_key "$scheme$request_method$host$uri$is_args$arg_id";<br>proxy_cache_valid 200 302 7d;<br>add_header Cache-Control "public, max-age=604800";<br>add_header ETag $upstream_http_etag;
- Node.js/Express 中手动加头：
res.set("Cache-Control", "public, max-age=604800").set("ETag", fileId)
机械硬盘场景下，chunkSize 才是缓存命中的前置条件
如果 chunk 太小（默认 255KB），一次图片请求触发 40+ 次磁盘寻道，哪怕 HTTP 缓存生效，首次加载也慢得无法接受——用户等不及就刷新，反而降低实际命中率。增大 chunk 是让“单次读取更快”，从而提升用户愿意等待并复用缓存的概率。
- 新建 bucket 必须显式指定：
new GridFSBucket(db, { chunkSizeBytes: 4 * 1024 * 1024 }) - 已有数据无法在线修改 chunk 大小，重传是唯一办法；别碰
files.chunkSize字段，驱动不识别 - 搭配
readPreference: "primary"（单机环境），避免驱动因错误配置多发无效请求
缓存命中率不是靠堆内存堆出来的，而是靠缓存键设计、HTTP 头控制、chunk 物理布局三者咬合。最容易被忽略的是：你加了 64GB 内存，但 Nginx 的 proxy_cache_path 还卡在默认 100MB，磁盘缓存区早被打满，新请求照样回源。
