缺复合索引{files_id:1,n:1}会导致MongoDB在并发下载时对fs.chunks执行索引扫描+内存排序，使find游标初始化变慢；应建此复合索引并确保files_id在前、n在后，且需配套优化连接池和流式读取。
为什么fs.chunks上缺复合索引会导致并发下载变慢
GridFS 下载时，open_download_stream 内部会根据 files_id 和 n（chunk 编号）查 fs.chunks 集合。如果只有默认的单字段索引 { files_id: 1 } 或 { n: 1 }，MongoDB 在高并发下容易触发索引扫描+内存排序，尤其是当文件很大、chunk 数量多（比如百万级）时，查询延迟明显上升，find 游标初始化变慢，stream 启动卡顿。
该建什么复合索引：{ files_id: 1, n: 1 } 是唯一合理选择
必须按这个顺序建，不能反过来：
-
files_id在前：确保能快速定位某一个文件的所有 chunks -
n在后：让 chunk 按编号物理有序，避免 sort 阶段；驱动读取时是顺序请求n=0,1,2...，复合索引天然支持范围扫描{ files_id: ObjectId(...), n: { $gte: 100 } } - 别加
data字段进去：它太大，索引体积爆炸，且不参与查询条件 - 别用稀疏索引或唯一索引：
n在不同files_id下可重复，不满足唯一性
建索引时的三个实操注意点
直接在 MongoDB Shell 中执行：
db.fs.chunks.createIndex({ "files_id": 1, "n": 1 })
- 建索引期间不影响读写，但会占用 I/O 和内存；生产环境建议在低峰期操作
- 如果已有大量数据，首次建索引可能耗时几分钟——别中断，否则索引处于
background未完成状态，后续查询仍走全表 - 验证是否生效：
db.fs.chunks.explain("executionStats").find({ files_id: ObjectId("..."), n: { $gte: 0 } })，看executionStages.stage是否为IXSCAN，且nReturned接近预期 chunk 数
仅建这个索引还不够：配套动作必须做
复合索引只是基础，没配好其他环节，性能照样卡在别处：
- 确保
fs.files上有{ _id: 1 }或{ filename: 1 }索引——find查文件元数据不能慢 - 并发下载多个文件时，每个子进程必须独立建
MongoClient，复用连接对象会导致连接池争用，索引再快也白搭 - 如果下载的是超大文件（>1GB），记得用流式读取（
for chunk in grid_out），否则.read()把整个文件加载进内存，先 OOM 再谈性能
真正拖慢并发下载的，往往不是磁盘或网络，而是查询路径上某个没被意识到的隐式排序或全集合扫描——而 { files_id: 1, n: 1 } 就是堵住这个缺口最直接的一块砖。
