sh.shardCollection()并非唯一命令，实际需先启用数据库分片、创建分片键索引、确保分片在线，再执行该命令；对非空集合分片后数据不自动分布，因MongoDB仅建初始chunk，依赖balancer异步迁移，且小集合或不合理分片键易导致单chunk堆积或写入热点。
sh.shardCollection() 是唯一能对已有集合启用分片的命令，但“聚集集合”这个说法在 MongoDB 语法中并不存在——你实际想操作的，是**已存在且有数据的集合（即非空集合）**。这类集合分片稍有不慎就会卡住、不迁移、查询变慢，甚至导致 mongos 路由失效。
为什么对非空集合分片后数据不自动分布？
MongoDB 不会主动拆分已有数据；它只在你调用 sh.shardCollection() 后创建一个初始 chunk（覆盖整个分片键范围），然后依赖 balancer 后续迁移。但 balancer 默认只在平衡窗口内工作，且不会拆分单 chunk，除非它超过 chunkSize（默认 128MB）。
- 如果你的集合很小（比如几 MB），它永远就只有 1 个 chunk，所有数据始终落在一个分片上
- 如果分片键选择不合理（如单调递增的
_id），新写入全挤在最后一个 chunk，造成热点 - balancer 可能被禁用，或配置了
disableBalancing，导致 chunk 零迁移
执行 sh.shardCollection() 前必须确认的三件事
跳过任意一项，分片后大概率“看起来成功了，实际没用”。
- 目标集合所在数据库必须已启用分片：
sh.enableSharding("mydb")，否则报错database not sharded - 分片键字段必须有支持的索引（如
{ shardKey: 1 }或{ shardKey: "hashed" }），且不能是稀疏索引或 TTL 索引 - 集群中至少有两个分片在线且状态为
READY（用sh.status()查看shards和chunks分布）
对已填充集合分片后的强制拆分与触发迁移
仅靠 sh.shardCollection() 不足以让小数据集立刻分散。你需要人工介入拆分 + 触发均衡：
- 先手动 split 初始 chunk：
sh.splitAt("mydb.mycoll", { shardKey: <first_value> })</first_value>（需知道分片键大致分布） - 或更稳妥地：用
sh.splitFind("mydb.mycoll", { shardKey: <some_value> })</some_value>指定拆分点 - 确保 balancer 开启：
sh.setBalancerState(true)，并检查sh.getBalancerState() - 必要时临时扩大平衡窗口：
sh.startBalancer({ waitForCompletion: true })强制立即运行一轮迁移
注意：split 命令必须在 admin 数据库下执行，且只能对已分片集合操作；对未分片集合直接执行会报 collection is not sharded。
容易被忽略的兼容性陷阱
MongoDB 6.0 对分片键变更和重新分片支持有限——它不支持直接修改已有分片键，也不支持 sh.rebalanceCollection() 这类旧命令。所谓“重新分片”，在 6.0 实际指“删库重建+重导数据”，或者升级到 7.0 后用 sh.reshardCollection()。
- 如果你误以为
sh.shardCollection()可重复执行来换分片键，它只会报already sharded - 使用
"hashed"分片键时，务必确认字段值分布足够离散；若字段大量重复或为 null，会导致所有文档落入同一 hash bucket - 分片键字段一旦写入，后续更新受限制：除
_id外可改，但改后可能触发跨分片迁移，产生隐式 writeConcern 延迟
真正麻烦的不是怎么分片，而是分片键选错之后没法在线修正——6.0 没有安全的在线重分片路径，这点比 7.0 严格得多。
