gridfs性能瓶颈主因是索引缺失、range未限制、chunks扫描、驱动重试失控；需为files建filename/uploaddate索引、chunks建files_id/n索引，下载时解析range头并设超时，禁用从节点读，显式控制重试与超时。
fs.files 查询慢，大概率是没建索引
GridFS 的 fs.files 集合默认只有 _id 索引，但业务里几乎不会只靠 _id 下载文件——更多是按 filename、uploadDate 或自定义字段（比如 metadata.projectId）查。一旦没对应索引，MongoDB 就得扫完整个 fs.files 集合，10 万文件起步时，单次查询就可能卡住整个副本集。
用这个命令快速验证是否在全表扫描：db.fs.files.find({ filename: "report.pdf" }).explain("executionStats")
重点看 executionStats.nReturned 和 executionStats.totalDocsExamined：如果后者远大于前者（比如返回 1 条却扫了 8 万文档），说明索引缺失或没命中。
- 高频按文件名查？建
{ filename: 1, uploadDate: -1 }复合索引，兼顾排序和范围查询 - 按项目 ID 查？别嵌在
metadata里模糊匹配（如{ "metadata.projectId": "abc" }），把projectId提到顶层字段再建索引 - 避免对
metadata做$in、$regex这类操作，它们基本不走索引，考虑物化字段或改用普通集合+对象存储
chunks 扫描拖垮性能，必须补 { files_id: 1, n: 1 } 索引
GridFS 下载分两步：先查 fs.files 拿元数据，再根据 files_id 和序号 n 去 fs.chunks 拼数据。第二步若无索引，就会变成 collection scan——而 chunk 数量通常是文件数的几百倍（默认 255KB/chunk），性能雪崩比 files 更快。
立刻执行：db.fs.chunks.createIndex({ files_id: 1, n: 1 }, { unique: true })
- 加
{ unique: true }是防重复 chunk，避免文件损坏 - 别用
{ files_id: 1 }单字段索引，它无法加速按n排序读 chunk 的过程 - 建完索引后，用
db.fs.chunks.getIndexes()确认是否存在该复合索引
驱动 findOne() 返回 undefined，可能是重试+超时叠加导致
看着只是 bucket.findOne({ filename: "x.pdf" })，但底层会发多次命令：先查 fs.files，再查 fs.chunks。网络抖动或主节点切换时，Node.js 驱动默认开启重试，而 GridFS 操作又没法原子回滚——结果就是查不到文件，还可能留下孤儿 chunk。
- 显式禁用重试：
findOne(..., { readPreference: "primary", maxTimeMS: 5000 }) - 别依赖
findOne()自动兜底，先用find().limit(1)+toArray()控制行为 - 监控日志里是否频繁出现
slow query且耗时集中在fs.chunks，那是索引或重试失控的典型信号
Range 请求没解析，服务端白读整文件
HTTP 客户端发了 Range: bytes=1024-2048，但服务端调用 bucket.openDownloadStream() 时没传 start/end，驱动就会从 GridFS 把整个文件读出来再裁剪——I/O 和内存压力翻倍，尤其大文件场景。
- 必须手动解析
Rangeheader，提取start和end，传给openDownloadStream({ start, end }) - 对 >50MB 的文件，加
stream.setTimeout(30000)，防慢连接长期占连接池 - 禁止在一个 HTTP 请求里并发开多个
openDownloadStream()（比如拼分片），GridFS 不适合高并发小块读，这类需求该上对象存储
真正容易被忽略的是：索引建了但查询条件顺序不对，或者用了 $or / $in 导致索引失效；还有清理失败上传留下的孤儿 chunk，它们不会自动删，只会越积越多拖慢后续所有查询。
