gridfs中fs.chunks不能建ttl索引，因mongodb明确禁止对系统集合设ttl索引，且其生命周期须由fs.files严格控制，否则将破坏读取一致性并引发chunknotfound异常。
GridFS 本身不支持 TTL，必须手动在 fs.files 上建 TTL 索引，并同步清理 fs.chunks，否则会留下大量孤儿块，持续占用磁盘空间。
为什么 fs.chunks 不能直接建 TTL 索引
MongoDB 明确禁止对 fs.chunks 创建 TTL 索引。官方文档和内核逻辑都限制了该集合的索引类型——只允许普通单字段或复合索引（如 files_id 和 n），expireAfterSeconds 选项会被拒绝并报错：Cannot create TTL index on system collection。这是因为 fs.chunks 是 GridFS 的底层分片载体，其生命周期必须严格由 fs.files 控制，不能独立过期。
常见错误现象：执行 db.fs.chunks.createIndex({ "uploadDate": 1 }, { expireAfterSeconds: 0 }) 会直接失败；即使绕过限制强行写入（如通过驱动伪造命令），mongod 启动时也会校验并拒绝加载该索引。
- TTL 索引仅适用于用户可写、语义明确的集合，
fs.chunks属于 GridFS 内部实现细节，不在支持范围内 - 即便技术上能绕过，也会破坏 GridFS 的读取一致性：
findChunksForFile()依赖files_id完整性，TTL 删除 chunk 会导致文件读取时抛出ChunkNotFound异常
如何正确设置 fs.files 的 TTL 并确保 expiresAt 生效
必须显式写入 expiresAt 字段（Date 类型），且不能复用 uploadDate —— 因为上传时间 ≠ 过期时间，业务含义模糊，且 uploadDate 是 GridFS 驱动自动注入的，你无法在写入时动态控制其值。
实操要点：
- Node.js 驱动中，用
bucket.uploadFromStream()时，在options中传入：{ metadata: { expiresAt: new Date(Date.now() + 3600000) } }；PyMongo 则用upload_from_stream(..., metadata={"expiresAt": datetime.utcnow() + timedelta(hours=1)}) - 创建索引命令必须是：
db.fs.files.createIndex({ "expiresAt": 1 }, { expireAfterSeconds: 0 })；expireAfterSeconds: 0表示“过期即删”，不是留空或省略 - 验证字段类型是否达标：
db.fs.files.findOne({ expiresAt: { $type: "date" } })应返回有效文档；若返回null，说明有大量字符串或缺失值，TTL 将跳过这些文档
如何安全清理 fs.chunks 中的孤儿块
TTL 删除 fs.files 文档后，对应 fs.chunks.files_id 变成悬空引用，MongoDB 不做级联删除。必须用外部机制配对清理，否则磁盘空间永不释放。
推荐做法（按可靠性排序）：
- 启用变更流监听
fs.files的delete事件（MongoDB ≥ 4.0），实时捕获被删的_id，立即触发db.fs.chunks.deleteMany({ files_id: { $in: [...] } }) - 若无变更流（如 MongoDB 3.6 或 Atlas 免费层），改用定时任务（每 5 分钟）执行两步查询：
db.fs.chunks.find({ files_id: { $nin: db.fs.files.distinct("_id") } }).limit(1000)→ 收集files_id→ 批量删除；注意加explain("executionStats")确认files_id已建索引，否则$nin查询极慢 - 绝对不要用
db.fs.chunks.remove({})清空再重建，会破坏所有未过期文件的完整性
容易被忽略的性能与监控盲点
TTL 后台线程每 60 秒扫描一次，但扫描行为受 mongod 负载抑制：高 CPU 或 I/O 压力下可能跳过本轮，延迟可达数分钟。更隐蔽的问题是，如果 fs.files 长期无新写入，TTLMonitor 可能完全停止扫描该集合——这在低频上传的生产环境很常见。
上线前必须检查三项：
-
db.fs.files.getIndexes()输出中是否有"expireAfterSeconds": 0条目 -
db.fs.chunks.getIndexes()中是否存在{ "files_id": 1 }索引（默认没有，必须手动建） -
db.adminCommand({ serverStatus: 1 }).metrics.ttl中passes是否随时间递增，deletedDocuments是否非零
真正棘手的不是“怎么设”，而是“怎么确认它一直在干活”。一旦漏掉其中一环，过期文件就变成静默存储负债。
