GridFS 的 fs.chunks 集合不自带压缩机制，其压缩效果取决于 WiredTiger 引擎的全局配置；手动修改已存在 fs.chunks 的存储参数无效，因 GridFS 自动创建且禁止 collMod；压缩需在 mongod 启动时通过 storage.wiredTiger.collectionConfig.blockCompressor 统一设置，并对新集合生效；已有集合需 compact 才能重写压缩；更高效做法是上传前压缩文件内容、调大 chunkSize、清理孤立 chunk。
GridFS 的 fs.chunks 集合本身不参与 MongoDB 级别的压缩，无论你是否启用 Snappy（或 zlib、zstd）——因为压缩发生在 WiredTiger 存储引擎层，而 fs.chunks 只是普通集合，它的压缩效果完全取决于所在数据库的全局或集合级配置，不是 GridFS 自身机制决定的。
为什么对 fs.chunks 手动启用压缩常无效
很多人执行 db.runCommand({collMod: "fs.chunks", index: {keyPattern: {...}}}) 或尝试用 createCollection 指定 storageEngine.wiredTiger.configString，但实际没效果，原因很直接：
-
fs.chunks是由 GridFS Bucket 自动创建的，不是用户显式建的集合；MongoDB 不允许对已存在的 GridFS 系统集合（fs.files/fs.chunks）执行collMod修改存储参数 - 即使你在建库前就配好
wiredTiger.configString，WiredTiger 对小文档（如默认 256KB 的 chunk）压缩收益极低：Snappy 压缩率通常仅 10%–20%，且 chunk 内部是二进制流，缺乏重复模式，zlib/zstd 也难起效 - 压缩开关必须在 集合创建时 指定，而 GridFS Bucket 初始化时不会读取你后来改的配置；
db.createCollection("fs.chunks", {...})会失败，因为该集合名已被 Bucket 占用
真正生效的压缩配置位置
要让 fs.chunks 落盘数据被压缩，唯一可靠路径是控制 WiredTiger 引擎的全局行为：
- 启动 mongod 时，在配置文件中设置：
storage.wiredTiger.collectionConfig.blockCompressor: snappy（或zlib/zstd），这个值对所有新创建的集合生效，包括后续 GridFS Bucket 自动建的fs.chunks - 注意：已有集合（比如已存大量文件的
fs.chunks）不会自动重写压缩，必须db.runCommand({compact: "fs.chunks"})—— 但 compact 期间会锁表，且只重排页，不改变文件系统占用（WiredTiger 不主动归还磁盘空间给 OS） - 验证是否生效：用
db.fs.chunks.stats()查看size（原始字节数）和storageSize（磁盘占用），若后者明显更小，说明压缩起效；若两者接近，大概率没压上或数据本身不可压
比压缩 chunks 更值得做的三件事
把精力花在压缩 fs.chunks 上，性价比远低于优化上游：
- 上传前压缩文件内容：用
sharp（图像）、ffmpy（视频）、zlib.gzipSync（文本）等处理原始 buffer，再喂给bucket.openUploadStream—— 这样每个 chunk 存的本身就是压缩后数据，storageSize自然下降 - 调大 chunkSize：初始化 Bucket 时传
{chunkSizeBytes: 1024 * 1024}（1MB），减少 chunk 文档数量，降低索引开销和元数据膨胀，对小文件尤其明显 - 删孤立 chunk：上传中断可能导致
fs.chunks里残留无对应fs.files记录的 chunk，它们既不被读取也不被压缩，定期用脚本清理比硬压更实在
真正影响磁盘的从来不是「要不要压 chunks」，而是「chunk 里到底存了什么」——压缩引擎再强，也压不出不存在的冗余。
