分片已有集合需先创建分片键索引，再通过admin库执行shardcollection；分片后数据初始集中于一个chunk，需依赖balancer迁移或手动预拆分实现均衡。
对已有集合分片不能直接用 shardCollection 就完事——如果集合已存在且有数据，必须先确保分片键字段上有对应索引，否则命令会失败。
分片前必须有分片键索引
分片键不是随便选的字段，MongoDB 要求该字段（或字段组合）上必须存在一个以它为前缀的索引。比如你要用 { "user_id": 1 } 当分片键，就得先建索引：
db.users.createIndex({ "user_id": 1 })
常见错误是跳过这步，直接跑 shardCollection，结果报错："cannot shard collection unless it has a shard key index"。
- 索引必须在
shardCollection命令执行前创建； - 如果集合为空，MongoDB 会自动建索引，但已有数据时不会帮你补；
- 哈希分片键（如
{ "user_id": "hashed" }）也一样要索引，且只能是单字段哈希； - 复合分片键如
{ "region": 1, "user_id": 1 }，索引必须严格按这个顺序，{ "user_id": 1, "region": 1 }不行。
shardCollection 命令要跑在 admin 库下
shardCollection 是管理命令，必须通过 admin 数据库执行，不能在业务库里直接调：
db.adminCommand({
shardCollection: "mydb.users",
key: { "user_id": 1 }
})
容易踩的坑：
- 误在
mydb下运行db.runCommand(...)，会提示权限错误或找不到命令； - 用
sh.shardCollection()辅助方法时，虽然不用切库，但它内部仍走adminCommand，所以前提条件（索引、权限）一个都不能少； -
unique: true只对范围分片有效，哈希分片不支持该选项，设了会报错。
分片后数据不会立刻均匀分布
对已有集合分片，MongoDB 默认只生成一个初始 chunk，覆盖整个分片键范围。后续靠 balancer 迁移 chunk 实现均衡——这意味着刚分片完，所有数据还在一个分片上，读写压力没分散。
如果你急需快速摊平数据，有两条路：
- 等 balancer 自动工作（默认每10分钟检查一次迁移机会），适合小到中等规模数据；
- 手动预拆分（
sh.splitAt()或sh.splitFind()），配合moveChunk把 chunk 按需挪到其他分片，适合大集合或对延迟敏感场景； - MongoDB 8.0+ 可用
reshardCollection+forceRedistribution: true强制重分布，但注意：它会重建整个集合，期间旧集合不可写，需评估业务容忍度。
真正麻烦的不是命令怎么敲，而是分片键选得是否合理——一旦数据量上来，改分片键代价极高。哪怕只是加个后缀字段优化，也要走重新分片流程，涉及全量数据拷贝和索引重建。所以分片前多花两小时想清楚 key，远比上线后再折腾强。
