db.fs.files的length字段不能直接求和，因存在文件删除后chunks未清理、length字段缺失或类型错误等问题，聚合前需用{$type:"long"}过滤并校验数据完整性。
为什么 db.fs.files 的 length 字段不能直接求和？
因为 GridFS 实际把文件切分成多个 db.fs.chunks 文档存储，而 db.fs.files.length 是单个文件的总字节数（即逻辑大小），它本身是可靠的。但直接对 db.fs.files 聚合求 sum 时，容易忽略两个关键问题：一是文档可能被删除但 chunks 未清理（导致 files 记录残留），二是某些驱动或旧版本写入时可能漏填 length（值为 null 或缺失）。所以聚合前必须加校验。
-
length字段必须存在且为数字类型，建议用{$type: "long"}或{$type: "int"}过滤 - 生产环境应同步检查
db.fs.chunks是否存在对应files_id，避免“幽灵文件”干扰统计 - 如果启用了分片集群，
db.fs.files集合不能直接跨分片聚合 sum——需先在各分片执行再合并，或改用mongos的分布式聚合（4.4+ 支持）
用聚合管道计算所有文件总容量的最小可行命令
这是最简、最安全的写法，适用于 MongoDB 4.0+：
db.fs.files.aggregate([
{ $match: { length: { $type: "long" } } },
{ $group: { _id: null, totalBytes: { $sum: "$length" } } }
])
返回形如 { "_id": null, "totalBytes": 1234567890 }。注意：
- 不要用
$sum: 1或$sum: "$_id"——那算的是文件数量，不是容量 - 若结果为
0或null，先运行db.fs.files.findOne({ length: { $exists: false } })看是否有脏数据 - 在 WiredTiger 引擎下，该聚合走索引效率很高；但若没建索引，首次执行可能扫描全集合——建议给
{ length: 1 }建稀疏索引：db.fs.files.createIndex({ length: 1 }, { sparse: true })
按文件类型（contentType）分组统计容量
GridFS 中常用 contentType 字段存 MIME 类型（如 "image/jpeg"、"application/pdf"），但该字段非必填，且格式不统一（空字符串、null、大小写混用都可能出现）。
- 先用
{$and: [{ contentType: { $ne: null } }, { contentType: { $ne: "" } }]}过滤有效值 - 加
{$toLower: "$contentType"}统一小写，避免"JPEG"和"jpeg"被拆成两组 - 示例管道：
db.fs.files.aggregate([
{ $match: {
length: { $type: "long" },
contentType: { $ne: null, $ne: "" }
}
},
{ $addFields: { lowerType: { $toLower: "$contentType" } } },
{ $group: {
_id: "$lowerType",
count: { $sum: 1 },
totalBytes: { $sum: "$length" }
}
},
{ $sort: { totalBytes: -1 } }
])
大文件场景下的性能与精度权衡
当文件平均大小 >10MB 或总量超 TB 级时，$sum 本身不会溢出（BSON long 支持 64 位有符号整数，上限约 9EB），但要注意：
- 聚合结果中的
totalBytes是NumberLong类型，在部分 MongoDB Shell 版本（如 4.4 以前）里可能显示为科学计数法——用.toString()查看原始值 - 如果业务要求“精确到 chunk 级”，必须关联
chunks计算：db.fs.chunks.aggregate([ { $group: { _id: null, total: { $sum: "$data.size" } } } ])，但这比查files.length慢 5–10 倍，且data.size是 BSON 二进制字段长度，不含 GridFS 元数据开销 - 真正影响速度的不是聚合本身，而是磁盘 I/O —— 如果
fs.files不在内存中，首次聚合会触发大量 page fault；建议在低峰期预热：db.fs.files.find({ length: { $exists: true } }).limit(1).toArray()
实际跑下来，千万级文件的 sum 聚合通常在秒级完成，但前提是 length 字段干净、有索引、且集合未严重碎片化。
