gridfs分片只能用_id字段且必须为hashed策略；files和chunks集合自动关联，其他字段（如files_id）不可作为分片键，否则报错；查询需依赖filename等字段的手动二级索引。
GridFS 分片不能用 files_id 作为分片键——这是常见误解，也是线上踩坑高发点。MongoDB 对 GridFS 的分片有硬性限制：fs.files 和 fs.chunks 都只允许以 _id 字段为分片键，且必须是 "hashed" 策略。任何尝试用 { files_id: 1 } 或 { files_id: 1, n: 1 } 对 fs.chunks 执行 shardCollection 的操作，在 MongoDB 6.0+（含当前 2026 年主流版本）中会直接报错：cannot shard collection with non-_id shard key on a GridFS namespace。
为什么 files_id 不能当分片键？
这不是设计疏漏，而是架构约束：
-
fs.files和fs.chunks是 GridFS 的逻辑绑定对，MongoDB 内部通过_id（即files._id）与chunks.files_id做强关联；若允许不同分片键，会导致元数据和数据块跨分片后无法原子读取或写入 - 分片命令只接受
sh.shardCollection("db.fs.files", { "_id": "hashed" })；执行后，fs.chunks会自动继承该策略，无需、也不允许单独操作fs.chunks - 所谓“用
{ files_id: 1, n: 1 }分片 chunks”的旧文档，仅适用于极早期 MongoDB（≤3.2）且未启用严格 GridFS 命名空间校验的场景，当前已彻底失效
正确分片方式：只用 _id: "hashed"
必须在启用分片前，对 fs.files 执行哈希分片：
sh.enableSharding("mydb")
sh.shardCollection("mydb.fs.files", { "_id": "hashed" })
之后所有写入的文件，其 _id（默认为 ObjectId）会被哈希后均匀分布到各分片。关键点：
- 不要等数据量大了再分片——GridFS 不支持后期修改分片键，已有数据需导出重建
- 确保驱动层生成的
_id具备足够散列度；若业务自定义_id（如时间戳字符串），需手动哈希后再赋值，否则仍会热点写入 -
fs.chunks无须建索引或分片命令，它会随fs.files自动路由，但你仍需手动为高频查询字段建二级索引，例如：db.fs.files.createIndex({ "filename": 1 })
查文件慢？问题不在分片键，而在索引缺失
由于分片键锁死为 _id，按 filename、uploadDate 或 metadata 查询时，mongos 必须广播请求到所有分片——这正是性能瓶颈根源。解决方式不是换分片键（做不到），而是补索引：
- 所有查询字段都需显式建索引：
db.fs.files.createIndex({ "filename": 1, "uploadDate": -1 }) - 避免在
metadata上建单字段索引（如{ "metadata.tag": 1 }），除非该字段基数高且查询频繁；低基数字段（如status只有 "active"/"deleted"）索引效果差，还拖慢写入 - 如果业务重度依赖时间范围查询（如“查最近 7 天上传的 PDF”），
"hashed"分片会丢失时间局部性，此时应评估是否真的需要 GridFS——小文件可改用 BinData 存单文档，配合uploadDate分片；大文件则考虑对象存储 + MongoDB 存元数据
真正容易被忽略的是：分片后 fs.files 的写入压力虽摊开了，但所有元数据读操作（比如根据 filename 查文件）默认变成全分片扫描。没建对索引，集群再大也扛不住并发查询——这不是分片失败，而是索引没跟上。
