GridFS并发写入卡住是因为fs.files集合写锁争用，尤其filename唯一索引加剧B-tree节点锁冲突；读取瓶颈则源于fs.chunks索引更新阻塞及查询未优化。
GridFS 写入时为什么一并发就卡住？
因为 GridFS 底层是往两个集合（fs.files 和 fs.chunks）里写文档，而每个文件的写入过程包含：先插入元数据（fs.files）、再分块插入数据（fs.chunks），中间还可能涉及自动创建索引、触发唯一约束检查等操作。这些都不是原子的单语句，更不是事务——在 WiredTiger 引擎下虽支持文档级锁，但 fs.files 的插入是集合级写锁，且多个客户端同时上传同名文件（或靠 filename 字段查重）时，极易在 fs.files 上形成写锁排队。
- 常见错误现象：
db.currentOp({"$all": true, "waitForLock": true})返回大量等待w（独占写锁）的操作，集中在fs.files集合 - 使用场景：多线程/多进程上传日志、图片、设备固件包，尤其当 filename 字段被用作业务主键（如
"report_20260312_deviceA"）并开启唯一索引时 - 性能影响：一个 5MB 文件拆成 ~20 个 chunk，需至少 21 次写入；若 100 个并发上传，
fs.files成为串行瓶颈，平均锁等待时间可能从毫秒级升至秒级
为什么 fs.files.filename 唯一索引会放大锁问题？
WiredTiger 虽支持文档级锁，但唯一索引检查需要先加意向锁（IX），再对候选文档加读锁（r），最后在插入时升级为写锁（w）。如果多个请求几乎同时写入相同 filename，它们会在索引 B-tree 的同一叶子节点上竞争，导致锁冲突概率陡增——这比普通字段查询高得多。
- 参数差异：默认
fs.files.filename没有索引；一旦手动加了{filename: 1}唯一索引，每次写入都要走完整索引查找+冲突检测路径 - 容易踩的坑：用
put()方法传filename时没意识到驱动会自动做 upsert 或重名覆盖逻辑，底层仍要查索引；有些驱动（如 PyMongo）甚至在put()前隐式执行find_one()判断是否存在 - 实操建议：改用自动生成的
_id（如 ObjectId）作为主标识，把业务名放进 metadata 字段；必须按名查文件时，单独建非唯一、稀疏索引（{metadata.device_id: 1, upload_time: -1}）代替 filename 唯一约束
GridFS 读取并发高时也会等锁？
会，但原因不同。读操作本身只持 r（共享锁），问题出在「元数据+数据块拼装」这个客户端行为上：驱动调用 get() 时，先查 fs.files 获取 chunk 数量和 _id，再批量发 find() 去 fs.chunks 拉数据。如果此时有其他写操作正在往 fs.chunks 插 chunk（比如另一个上传未完成），WiredTiger 对 fs.chunks 的 collection-level 索引更新可能短暂阻塞读请求的 chunk 查询——尤其当 chunk 数量大、查询条件没走好索引时。
- 常见错误现象：监控看到
globalLock.ratio正常，但locks.database.<db>.acquireWaitCount</db>在fs.chunks上持续上升 - 实操建议：确保
fs.chunks有复合索引{files_id: 1, n: 1}（GridFS 默认建，但分片集群中可能丢失）；避免用find({})扫全量 chunks；读大文件时启用流式读取（如 Node.js 的openDownloadStream()），别一次性toArray() - 兼容性注意：MongoDB 6.0+ 对
fs.chunks.n字段做了优化，但老版本（如 4.4）在高并发 range query（如视频 seek）时仍可能因索引扫描范围过大引发锁等待
有没有真正绕过锁的替代方案？
有，但得接受取舍。GridFS 本质是“用通用文档模型模拟文件系统”，高并发下它不如原生文件存储轻量。真要扛住万级上传/下载，优先考虑：
- 静态资源走对象存储（如 S3 / MinIO），MongoDB 只存 URL 和 metadata；
fs.files那套双集合结构完全不用了 - 小文件（BinData 存进业务集合，例如
{type: "log", content: BinData(0, "..."), ts: ISODate()}；省去 GridFS 的路由开销，锁粒度降到文档级 - 必须用 GridFS 且并发极高？把上传路由到专用分片（shard key 设为
{_id: "hashed"}），并禁用fs.files.filename唯一索引——用应用层保证不重复，比数据库锁便宜得多
最常被忽略的一点：GridFS 的 chunk 大小默认 255KB，上传 1GB 文件会生成近 4000 个文档。这个数量级下，fs.chunks 的索引维护成本本身就可能触发 WiredTiger 的内部 page lock，跟业务代码是否写得好关系不大——这时候调小 chunkSize（比如设成 1MB）反而更能降低锁竞争，别迷信“越小越好”。
