gridfs分片键只能是_id且必须为hashed策略，mongodb 6.0+禁止使用files_id、filename等其他字段分片，否则报错；正确操作仅sh.shardcollection("db.fs.files", {"_id": "hashed"})，fs.chunks自动继承，无需也不允许单独分片。
GridFS 分片键只能是 _id，且必须用 "hashed"
别试 files_id、filename 或复合字段——MongoDB 6.0+ 会直接拒绝，并报错：cannot shard collection with non-_id shard key on a GridFS namespace。这不是配置问题，是硬性限制：GridFS 的 fs.files 和 fs.chunks 是强绑定逻辑对，fs.chunks.files_id 必须严格等于 fs.files._id，分片键若不统一，跨分片读写就无法保证原子性。
正确操作只有一步：sh.shardCollection("mydb.fs.files", {"_id": "hashed"})。执行后，fs.chunks 自动继承该策略，无需、也不允许单独对它执行 shardCollection。
- 必须在写入任何文件前启用分片；已有数据无法修改分片键，只能导出重建
- 如果业务自定义
_id（比如用时间戳字符串），要先哈希再赋值，否则仍会热点写入 -
fs.files分片后，fs.chunks不需要建索引，但fs.files上所有高频查询字段都得手动建二级索引
为什么按 filename 查得慢？不是分片键的问题，是没建索引
分片键锁死为 _id，意味着所有不带 _id 的查询（比如 find({ filename: "report.pdf" })）都会广播到全部分片。这不是“分片设计失败”，而是默认行为——mongos 必须查遍所有分片才能凑齐结果。
解决方式只有一种：显式建索引。例如：
db.fs.files.createIndex({ "filename": 1 })
更推荐组合索引，覆盖常见查询模式：
-
db.fs.files.createIndex({ "filename": 1, "uploadDate": -1 })—— 支持按名查 + 按时间排序 -
db.fs.files.createIndex({ "metadata.type": 1, "uploadDate": -1 })—— 如果常按类型+时间过滤 - 避免单字段索引如
{"metadata.tag": 1}，除非该 tag 基数高、分布均匀；否则容易形成不可拆分的大 chunk
别信“用 { files_id: "hashed" } 分片 chunks”的旧文档
网上有些教程说可以单独对 fs.chunks 执行 sh.shardCollection("mydb.fs.chunks", { "files_id": "hashed" })，这在 MongoDB ≤3.2 且未开启严格命名空间校验时可能“碰巧”跑通，但当前所有主流版本（包括 2026 年仍在维护的 7.x/8.x）已彻底禁用该路径。
尝试会立即失败，错误信息明确指向 GridFS 命名空间限制。真正起作用的只有 fs.files 上的 _id 哈希分片，其余都是干扰项。
- 不要在
fs.chunks上建任何索引——它由驱动自动管理，额外索引无意义且拖慢写入 - 不要试图用
refineCollectionShardKey修改 GridFS 分片键——该命令不支持 GridFS 集合 - 不要依赖
files_id字段做路由或聚合——它只是副本字段，不是分片依据
真正影响性能的，是查询模式和索引覆盖度
很多人花大量时间纠结“哪个字段当分片键更好”，但在 GridFS 场景下，这个纠结本身是错的起点。分片键没得选，关键在后续使用方式：
- 高频按
filename查？必须建filename索引，且注意字符串长度和重复率；大量同名文件（如日志access.log）会导致索引条目集中，考虑加时间戳或哈希后缀 - 需要范围查询（如某时间段上传的所有 PDF）？组合索引比单字段更有效，且避免全分片扫描
- 写入吞吐上不去？检查客户端是否批量生成
ObjectId——连续生成的 ObjectId 有时间局部性，即使哈希后也可能轻微倾斜；可改用UUID()或带随机盐的自定义 ID
最常被忽略的一点：GridFS 查询慢，90% 不是因为分片，而是因为忘了在 fs.files 上建对应索引。分片键是基础设施，索引才是查询性能的开关。
