fs.chunks缺{files_id: 1}索引导致全表扫描是GridFS下载慢的首要原因，需手动创建该索引；同时须弃用已废弃GridFS类、控制并发流数量、确保分片键一致，并全程管控流生命周期。
fs.chunks 缺索引导致全表扫描
GridFS 下载慢的首要原因不是网络或磁盘，而是 fs.chunks 集合没建 { files_id: 1 } 索引。驱动每次下载都要按 files_id 查所有 chunk，没索引就是全表扫描——哪怕文件只有 1MB，也可能扫几万行。
- 执行
db.fs.chunks.getIndexes()，确认输出里有{ "files_id": 1 } - 如果没有，立刻补：
db.fs.chunks.createIndex({ "files_id": 1 }) - 别依赖“驱动自动建”——手动创建集合、迁移旧数据、或用非标准桶初始化时，索引大概率缺失
- 加完索引后，用
db.currentOp({ "ns": /^your_db_name\.fs\.chunks$/ })观察 chunk 查询的secs_running是否明显下降
误用已废弃 GridFS 类引发内存与性能问题
Java 或 Node.js 项目若还在用老式 GridFS（如 Java 的 com.mongodb.gridfs.GridFS，Node.js 的 new mongodb.GridFS(db)），会触发串行 chunk 查询 + 全量加载到内存，OOM 和超时风险极高，且对缺失索引更敏感。
- Node.js 必须改用
new mongodb.GridFSBucket(db)，所有操作走openDownloadStream()或openDownloadStreamByName() - Java 项目必须迁移到
com.mongodb.client.gridfs.GridFSBucket，弃用所有GridFSDBFile相关 API - 老类不支持流式背压，一个 100MB 文件可能瞬间吃掉几百 MB 堆内存
并发流未受控导致连接池与内存耗尽
多个用户同时下载同一文件看似无害，但每个 openDownloadStream() 都会占用一个数据库连接和独立缓冲区。高并发下不是 GridFS 本身卡住，而是 maxPoolSize 耗尽、Node.js Buffer 积压或 OS 文件描述符打满。
- 用
p-limit控制同时打开的下载流数量，建议 ≤ 5（尤其前端做 Range 分片请求时） - 必须监听
error事件并显式销毁流：stream.destroy()，否则错误流残留会持续占连接和内存 - 响应层需防超时：Nginx 默认
proxy_read_timeout 60s，大文件下载要调高，或定期res.write('')发心跳保活 - 用户关闭浏览器或断网时，Node.js 不会自动 cleanup 流，得靠
req.on('close', () => stream.destroy())
分片集群中 fs.files 与 fs.chunks 分片键不一致
在分片集群上，如果 fs.files 和 fs.chunks 没配对分片，mongos 就得广播查询或跨分片 JOIN，一次下载可能触发几十次远程请求，延迟陡增。
-
fs.files推荐用业务字段分片，如{ user_id: 1 }或{ filename: "hashed" } -
fs.chunks必须用{ files_id: 1 }或{ files_id: "hashed" }，确保 chunk 与元数据共置在同一分片 - 执行前先确认
fs.chunks.files_id有索引：db.fs.chunks.createIndex({ files_id: 1 }) - 用
explain("executionStats")查fs.chunks.find({ files_id: ObjectId(...) })，确认nShards= 1
