在使用MongoDB存储大文件时，GridFS是最常用的方案。不过不少人在操作fs.files集合时遇到过这样的报错：Cannot index keys, or file md5... error code 1870，或者更直接的提示files collection must have an index on filename and uploadDate。这个错误码1870指向的问题非常明确：GridFS的files集合缺失了必需的唯一索引。看起来只是少一个索引，但如果不理解背后的机制，盲修往往修不好，甚至会让问题反复出现。
错误1870产生的根本原因
GridFS并不是MongoDB的一个独立功能模块，而是基于两个普通集合实现的存储约定：fs.files和fs.chunks。当你通过驱动上传一个文件时，文件被切分成若干个chunk存入chunks集合，而文件的元数据（文件名、长度、MD5、上传时间等）则作为一条文档存入files集合。为了能够按文件名和上传时间唯一定位一个文件，规范要求files集合上必须存在一个{filename: 1, uploadDate: 1}的复合唯一索引。
各种官方驱动在执行写入操作前，都会先做一次前置检查：确认files集合上是否存在这个索引。如果检查不到，驱动就会抛出1870错误并拒绝写入。这是驱动层面的保护机制，目的是防止同一文件名写入多条无法区分的记录。所以这个错误通常出现在以下几种场景：第一种是有人手动执行了dropIndexes把索引删掉了；第二种是集合被drop后用普通方式重建，没有恢复索引；第三种是用了非标准工具（比如某些迁移脚本）直接往files集合灌数据，绕过了GridFS API导致索引状态异常。
还有一种容易被忽视的情况：应用连接的GridFS bucket名称不是默认的fs。如果你的代码里创建bucket时指定了自定义前缀，比如mybucket，那么实际的集合名是mybucket.files和mybucket.chunks。如果你只检查了fs.files，自然找不到问题所在。排查时务必先确认bucket名称，这一点后面会详细说明。
如何确认索引是否真的缺失
修复之前，先要用命令确认现状。登录mongo shell（或mongosh），切换到对应的数据库，执行以下命令查看files集合的全部索引：
use mydb db.fs.files.getIndexes()
正常情况下，输出中应该能看到类似这样的索引定义：
{
"v" : 2,
"key" : { "filename" : 1, "uploadDate" : 1 },
"name" : "filename_1_uploadDate_1",
"unique" : true
}
重点核对三件事：索引的key是否同时包含filename和uploadDate两个字段、字段顺序是否为升序（1）、unique属性是否为true。任何一项不满足，驱动的前置检查都可能失败。另外还要检查集合本身是否存在：
db.getCollectionNames().filter(function(name) {
return name.indexOf("files") !== -1;
})
这条命令会列出所有名字包含files的集合，可以快速确认是否有自定义bucket的集合被遗漏。如果发现报错的应用使用的是自定义bucket，就把前面的getIndexes命令换成对应的集合名再查一次。
修复方案与操作步骤
最直接的修复方式是手动补建索引。在确认没有重复数据的前提下，执行：
db.fs.files.createIndex(
{ "filename" : 1, "uploadDate" : 1 },
{ "unique" : true }
)
如果files集合中已经存在filename和uploadDate组合重复的文档，createIndex会失败并提示重复键错误（错误码11000）。这时需要先找出重复的记录并处理掉。可以用聚合管道定位重复数据：
db.fs.files.aggregate([
{
$group: {
_id: { filename: "$filename", uploadDate: "$uploadDate" },
count: { $sum: 1 },
ids: { $push: "$_id" }
}
},
{ $match: { count: { $gt: 1 } } }
])
找到重复文档后，根据业务判断保留哪一条。因为GridFS存储的文件内容在chunks集合中，删除files文档并不会自动清理对应的chunks数据，所以如果确定要删除某条记录，最好同时清理对应的chunks，否则会留下孤儿数据占用磁盘空间。完整的安全删除流程是：先通过文件的_id查询chunks确认存在，再分别删除两个集合中的相关文档。
索引建好之后，建议用一段简单的驱动代码验证写入是否恢复正常。以Python的pymongo为例：
from pymongo import MongoClient
from gridfs import GridFS
client = MongoClient("mongodb://127.0.0.1:27017")
db = client["mydb"]
fs = GridFS(db)
# 上传一个测试文件，验证1870错误是否消失
file_id = fs.put(b"hello gridfs", filename="test.txt")
print(file_id)
如果这段代码执行成功并返回了文件id，说明索引已经修复到位。
如何避免问题再次发生
这类故障几乎都源于人为误操作，所以预防比修复更重要。第一，严格控制生产环境的dropIndexes权限，索引变更应走规范的变更流程，避免运维人员在线上随手执行删除操作。第二，任何针对GridFS集合的数据操作都应通过驱动提供的GridFS API完成，不要直接用insert、update操作fs.files集合，否则既容易破坏索引约定，也可能造成files和chunks数据不一致。
第二，如果项目使用了自定义bucket名称，务必在文档中记录清楚，排查问题时才不会走弯路。可以在应用启动时增加一段健康检查逻辑，验证files集合的索引是否存在，缺失时立即告警，这样问题在影响业务之前就能被发现。另外，做数据库迁移或备份恢复演练时，要特别留意索引是否被完整保留，mongorestore默认会恢复索引，但如果迁移脚本是自己写的批量导数据，索引就需要手工补建。
最后提一点经验之谈：遇到1870错误时不要急着重建整个GridFS bucket。有些人在网上看到重建bucket的建议就直接drop掉集合重来，结果导致存量文件全部丢失。只要按上面的步骤补回索引，绝大多数情况下服务就能立即恢复，数据也不用动。只有确认数据本身已经损坏或不可用时，才考虑更彻底的重建方案。
MongoDB故障码1870GridFSfiles集合索引修改时间：2026-09-11 13:42:38