chunks.files_id索引才是内存大户，因千万级文件×平均50片达5亿索引项，且files_id类型（如uuid或url）越长，单条索引内存涨3–6倍以上，易挤占wiredtiger缓存；确认无直查chunks需求时可安全删除该索引。
chunks.files_id 索引才是内存大户
GridFS 的索引内存压力，90% 以上来自 fs.chunks 集合上默认创建的 { files_id: 1 } 索引，而不是 fs.files._id。因为每张图片被切分成多个 chunk（默认 256KB/片），一张 10MB 图片就有约 40 条 chunk 文档，每条都带一个 files_id 字段并参与索引。千万级文件量 × 平均 50 片 = 5 亿级索引项，B-tree 节点缓存直接吃满 WiredTiger cache。
files_id 类型直接影响单条索引内存开销
files_id 值等于 fs.files._id，所以它的类型决定索引项大小：
- 用默认
ObjectId（12 字节固定长）：索引紧凑，B-tree 分支效率高 - 若业务强制设为 UUID 字符串（36 字符 UTF-8，约 36–72 字节）：单条索引项内存涨 3–6 倍
- 若用原始 URL 或 filename 作
_id（如"https://xxx/abc.jpg"）：长度上百字节，索引膨胀剧烈，cacheSizeGB 很快告急
WiredTiger 不区分“索引页”和“数据页”，所有 B-tree 页面共享同一块缓存池——files_id 越长，越容易把热 chunk 数据页挤出缓存，反而导致读图变慢。
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
删掉 files_id 索引真的安全吗
可以删，且 GridFS 正常工作，但必须确认使用场景：
- 生产环境只通过
GridFSBucket.openDownloadStream()或.find()访问文件 → 不依赖fs.chunks.find({ files_id: ... })→ 可删 - 有自定义 chunk 扫描、修复逻辑，或监控脚本直查
fs.chunks→ 删了会失效 - 老版本 MongoDB（{ files_id: 1, n: 1 }，得用
db.chunks.dropIndex({ files_id: 1, n: 1 })一起删
执行前先运行 db.chunks.getIndexes() 看清索引名，再备份：mongodump --db yourdb --collection fs.chunks --query '{"files_id": {"$exists": true}}' -o /tmp/chunks-index-backup。
别忽略 chunks 数据页对缓存的隐性挤压
即使删了 files_id 索引，fs.chunks.data 字段本身虽不建索引，但频繁读图会把大量 BSON 数据页载入 WiredTiger 缓存。这些页和索引页争内存，结果是：索引查询响应变慢、page eviction 加剧、cache overflow 日志增多。这时候光看 cacheSizeGB 不够，得盯 db.serverStatus().wiredTiger.cache["bytes currently in the cache"] / db.serverStatus().wiredTiger.cache["maximum bytes configured"] 比值——超 90% 就得调大。
