GridFS chunkSize默认255KB，调整需权衡空间与查询压力；fs.files索引膨胀可达3–5倍；租户隔离导致集合数量激增引发性能问题；流式下载须控制buffer防OOM；实际容量比原始文件大30–80%。
GridFS chunkSize 设置直接影响空间和查询压力
默认 chunkSize 是 255KB，不是 256KB——这是驱动实现细节，别按 256KB 做容量预估。改小（如 64KB）会让单个文件生成更多 fs.chunks 文档，显著增加索引体积、写放大和查询扫描量；改大（如 1MB）虽减少文档数，但小文件读取时会多加载无用字节，且内存缓冲压力上升。
企业级建议：保持默认 255KB，或统一设为 512KB。后者在中大型文件（10–100MB）场景下更平衡，但需确认业务中极少有小于 512KB 的高频访问文件，否则首块加载延迟明显。
- 计算公式：单文件 chunk 数 ≈
Math.ceil(fileSize / chunkSize)，每个 chunk 还带约 120 字节 BSON 开销 -
fs.chunks文档平均大小 =chunkSize + ~120，别忽略这 120 字节——百万级小文件下它能吃掉几 GB 空间 - 副本集同步压力随 chunk 文档数线性增长，分片集群下 chunk 分布不均还可能引发热点
元数据膨胀比常被低估：files 集合不是“只存一行”
fs.files 每条记录不只是 filename 和 uploadDate。你加的 metadata 字段全算进 BSON 大小，且每字段都参与索引构建。比如存了 { userId: ObjectId, tags: ["a","b"], checksum: "sha256..." }，这条文档轻松超 2KB —— 而不是你以为的“几十字节”。
更关键的是：fs.files 上建的复合索引（如 { "metadata.userId": 1, "uploadDate": -1 }）实际占用空间可能是原始文档的 3–5 倍，尤其当 tags 是数组时，索引条目会按元素展开。
- 务必对
fs.files执行db.fs.files.stats()查看avgObjectSize和totalSize，别只看文件数量 - 避免在
metadata中存冗余字段（如重复filename或完整路径），用业务 ID 替代字符串名 - 定期运行
db.fs.files.getIndexes()检查是否有未使用的索引——它们持续消耗磁盘和内存
租户隔离用 bucketName 时，集合数量=容量隐性成本
每个租户一个 bucketName，等于每个租户独占一对集合：tenant_xxx.files 和 tenant_xxx.chunks。MongoDB 对单个数据库内集合数量没有硬限制，但超过 1000 个集合后，启动时间、配置同步、WiredTiger 缓存管理开销会明显上升。
更隐蔽的问题是：WiredTiger 引擎为每个集合维护独立的 cache page 和 journal 文件。1000 个租户意味着至少 2000 个活跃集合句柄，这对连接池和 maxConns 配置形成压力，尤其在副本集选举后重建连接时易触发 Too many open files 错误。
- 不要用动态租户名直接拼接
bucketName后就扔进生产——先做db.getCollectionNames().filter(n => n.startsWith('tenant_')).length监控阈值 - 如果租户数预期超 500，考虑合并策略：按租户规模分组（如 VIP 租户独享 bucket，中小租户共享 bucket +
metadata.tenantId过滤），并确保该 bucket 的索引覆盖过滤字段 - 删除租户时，必须显式执行
db.dropCollection('tenant_xyz.files')和db.dropCollection('tenant_xyz.chunks')，否则集合残留会持续占用 namespace slot
流式下载没控制 buffer，OOM 风险比磁盘还急迫
调用 openDownloadStream 后直接 .pipe(res) 看似简单，但驱动默认用 Node.js Readable 的 highWaterMark=64KB 缓冲。当并发下载 100 个 500MB 视频时，瞬时内存峰值可能突破 3GB——远快于磁盘填满速度。
这不是理论风险：K8s 环境下 OOMKilled 往往发生在磁盘使用率才到 60% 的时候，因为内存先爆了。
- 始终设置
highWaterMark：例如bucket.openDownloadStream(fileId, { highWaterMark: 1024 * 1024 })（1MB） - 对大文件启用 HTTP Range 请求支持，用
req.headers.range构造options传给openDownloadStream，避免整文件加载 - 监控
process.memoryUsage().heapUsed并告警，阈值设为容器内存 limit 的 70%，别等 GC 触发
实际容量规划不能只算“文件总大小 × 1.2”，必须把 fs.chunks 的 BSON 开销、fs.files 的索引膨胀、租户集合的 namespace 占用、以及流式下载的内存 buffer 全部摊进去——这些加起来常比原始文件大 30–80%。
