gridfs在分片集群中不自动分片，必须手动对fs.files和fs.chunks集合分别配置分片键：fs.files推荐用filename或user_id等业务字段，fs.chunks必须用files_id哈希分片以保证共置，否则跨分片查询导致性能断崖下降。
分片集群本身不直接提升大文件（如 GridFS 存储的文件）的单文件读写性能，它解决的是整体吞吐和容量瓶颈。真正影响大文件性能的是 GridFS 分块大小 + 分片键设计 + 查询路由方式——这三点没对齐，加再多分片也白搭。
GridFS 文件元数据必须包含分片键字段
GridFS 本质是两个集合：fs.files 存元数据，fs.chunks 存数据块。默认情况下，这两个集合都不分片，即使你启用了分片集群，它们仍落在主分片上，变成单点瓶颈。
必须显式对这两个集合分片，且分片键要能支撑你的访问模式：
-
fs.files推荐用filename或业务 ID 字段（如user_id）作为分片键，避免时间戳类单调值 -
fs.chunks必须用files_id（即对应fs.files._id）作为分片键前缀，否则 chunk 无法与文件元数据共置，跨分片 JOIN 会拖垮性能 - 执行分片前确保
files_id字段在fs.chunks上有索引：db.fs.chunks.createIndex({files_id: 1})
chunkSize 设置不当会让分片失效
GridFS 默认 chunkSize 是 256KB，这个值在分片环境下可能引发严重倾斜：小文件生成大量 chunk，全挤在同一个分片；大文件的 chunk 虽多，但若 files_id 分布不均，依然会热点集中。
调整建议：
- 若文件按用户隔离（如每个
user_id上传若干文件），chunkSize可保持默认或略增大到 512KB，重点保证fs.files的user_id分片均匀 - 若文件类型混杂且无强业务键，改用复合分片键：
{filename: "hashed"}或{uploadDate: "hashed"}，此时chunkSize建议固定为 1MB 以上，减少 chunk 文档总数，缓解元数据压力 - 绝对不要设
chunkSize> 8MB——WiredTiger 单文档上限是 16MB，但 chunk 还要携带额外元数据，超限会导致写入失败并报错：Document too large
mongos 路由行为会放大随机读开销
GridFS 的典型读流程：先查 fs.files 拿 _id，再用该 _id 去 fs.chunks 拉所有 chunk。如果两个集合分片键不一致，mongos 就得广播查询或多次路由，延迟陡增。
验证是否踩坑的方法：
- 开启慢日志：
db.setProfilingLevel(1, {slowms: 100})，观察fs.chunks查询是否频繁出现scatter-gather模式 - 用
explain("executionStats")查fs.chunks.find({files_id: ObjectId(...)})，确认nShards是否等于实际分片数 - 检查
sh.status()输出，确认fs.files和fs.chunks的分片状态、chunk 分布是否均衡（尤其注意chunks集合的files_id是否被哈希打散）
最常被忽略的一点：分片后 GridFS 的 findOne 和流式读取（如 openDownloadStream）行为不变，但底层请求已分散。如果你的应用层做了并发 chunk 请求合并或缓存，务必确认这些逻辑没假设“所有 chunk 在同一节点”——否则会在分片环境下静默出错或降级。
