调大decompressBufferSize无效，因该参数仅影响网络协议层解压，与GridFS文件内容无关；CPU高主因是机械硬盘随机I/O叠加高频BSON chunk解析和内存拷贝，应优先调大chunkSizeBytes至1MB～4MB以减少解析次数。
GridFS 读取大文件时 CPU 高，通常不是解压问题，而是驱动反复解析 BSON chunk 文档 + 内存拷贝造成的——尤其在机械硬盘上叠加随机 I/O 时更明显。
为什么调大 decompressBufferSize 基本无效
GridFS 本身不压缩数据（除非你手动用 zlib 包裹流再存），decompressBufferSize 是 MongoDB 驱动里为 snappy/zstd 等 wire protocol 压缩预留的缓冲区，只影响客户端与服务器间网络包解压，和 GridFS 文件内容无关。你在读一个 100MB 视频时看到 CPU 飙升，99% 概率跟这个参数没关系。
- 该参数默认值（如 Node.js driver 是
32 * 1024）已足够处理单个 BSON 文档解包 - 增大它不会减少 chunk 解析次数，也不会跳过 BSON 反序列化开销
- 盲目调大反而可能触发 GC 频繁或内存碎片，尤其在 Node.js 的 V8 环境下
真正吃 CPU 的三个环节及对策
用 mongostat 或 db.currentOp() 观察到高 CPU 且伴随大量 getMore 或 find 操作时，问题大概率出在这三处：
-
chunk 文档高频反序列化：每个 255KB chunk 是一个独立 BSON 文档，驱动要逐个解析
_id、n、data字段。改用chunkSizeBytes: 4 * 1024 * 1024后，chunk 数量减少 16 倍，反序列化调用次数直降 -
流式读取中的内存拷贝：Node.js driver 默认把每个 chunk 先完整读进 Buffer，再 pipe 出去。对大文件，这会造成频繁的
Buffer.concat()或stream.write()开销。改用openDownloadStream()返回的Readable流，并直接pipe()到响应或文件写入流，避免中间 Buffer 拷贝 -
元数据查询冗余：先
files.find({ filename: "xxx" })再openDownloadStream(file._id)会多一次 round-trip 和 BSON 解析。直接用bucket.openDownloadStreamByName("xxx")（MongoDB 4.4+）可合并这两步
检查是否被 BSON 解析拖累的快速方法
在应用层加一行日志，捕获单次下载中实际解析的 chunk 数量：
const stream = bucket.openDownloadStreamByName("video.mp4");
let chunkCount = 0;
stream.on("data", () => chunkCount++);
stream.on("end", () => console.log("parsed chunks:", chunkCount));如果平均文件 50MB 却解析了 200+ 个 chunk，说明还在用默认 255KB 分块——这是 CPU 高的最常见根源，优先改 chunkSizeBytes。
别在驱动参数里找“解压开关”，GridFS 的瓶颈从来不在传输层压缩，而在磁盘寻道 + BSON 解析 + 内存流转这三道坎上。机械硬盘环境下，调大分块尺寸比调任何缓冲区都管用。
