GridFS分片只能用_id字段，且必须为hashed策略；files和chunks集合自动关联，其他字段无法作为分片键；查询需依赖filename或metadata等字段的手动二级索引。
GridFS 分片必须用 _id 字段，其他字段无效
GridFS 本身不支持对 files 或 chunks 集合任意字段分片——MongoDB 强制要求：只有 _id 字段能作为分片键。这是硬性限制，不是最佳实践建议。试图用 filename、uploadDate 或自定义字段建分片会直接报错 cannot shard collection with non-_id shard key on a GridFS namespace。
原因很简单：GridFS 是两个集合（files 和 chunks）的逻辑封装，MongoDB 内部通过 _id 关联二者。若允许其他分片键，会导致文件元数据和实际数据块跨分片后无法保证原子性或一致性。
- 分片命令只能写成：
sh.shardCollection("mydb.fs.files", { "_id": "hashed" }) -
fs.chunks会自动继承fs.files的分片策略，无需、也不能单独操作 - 如果你已有非
_id分片键的普通集合，别指望 GridFS 能复用它
选 "_id": "hashed" 还是 "_id": "ascending"？
绝大多数场景下，"_id": "hashed" 是唯一合理选择。默认 ObjectId 本身是时间+机器+进程+计数器组成的，按升序插入时天然导致“热点写入”——所有新文件都落在同一个分片上，彻底失去分片意义。
而 hashed 策略把 _id 哈希后均匀分布，写入压力才能摊开。但要注意：哈希后就失去了按时间范围查询的能力（比如“查昨天上传的所有文件”），因为哈希打乱了顺序。
- 用
hashed：适合高并发上传、文件大小较均匀、不依赖时间范围扫描的场景 - 用
ascending：仅限极小集群、调试用途，或你完全控制_id生成逻辑（例如自己构造带时间戳的字符串 ID 并确保散列度） - 不要尝试复合分片键，
{ "_id": 1, "uploadDate": 1 }这类写法在 GridFS 中语法非法
真正影响性能的其实是 filename 和 metadata 查询方式
既然分片键锁死在 _id，那怎么高效查文件？答案是：靠二级索引，而不是分片键。GridFS 不会自动为 filename 或 metadata 字段建索引，你得手动加。
比如经常按名字查，就在 fs.files 上建：db.fs.files.createIndex({ "filename": 1 })；如果常按用户 ID 查，就建 { "metadata.userId": 1 }。这些索引决定了查询是否走全表扫描，直接影响响应速度。
- 注意
filename字段默认无索引，不做优化时，单次findOne({ filename: "xxx" })可能扫遍所有分片 -
metadata是 BSON 对象，嵌套字段索引要写全路径，比如metadata.tags.0和metadata.tags效果不同 - 避免在
metadata里存大文本或数组，否则索引体积膨胀，拖慢写入
容易被忽略的坑：分片后 find() 返回游标不保证顺序
GridFS 分片后，fs.find().sort({ uploadDate: -1 }).limit(10) 这种写法看似正常，实则危险。MongoDB 分片查询默认不合并排序结果，每个分片各自返回 top 10，再由 mongos 合并——最终结果可能漏掉真正最新的文件。
必须显式加 .allowDiskUse(true) 并确认 mongos 版本 ≥ 4.2，否则可能内存溢出或结果错乱。更稳妥的做法是：用精确条件（如 _id 或带索引字段）过滤后再排序，或者接受最终结果不严格保序。
- 不要依赖
uploadDate排序做分页，尤其当文件量大、分片多时 - 如果业务强依赖时间顺序，考虑在应用层缓存最新文件 ID 列表，而非每次从 GridFS 扫
- 分片集群中，
countDocuments()比estimatedDocumentCount()慢得多，慎用于高频统计
_id 是唯一入口这个事实——所有优化都要绕着它设计，而不是幻想换个键就能一劳永逸。 
