sh.addshard()仅注册分片不触发迁移；数据流入需balancer开启且chunk差异超阈值（默认8）；多级扩容须单次加1分片，避免过载。
直接回答：sh.addShard() 本身只负责“挂载”，不能自动触发数据迁移；多级扩容必须配合分片键设计、均衡器状态、chunk 拆分策略和手动干预，否则新分片长期空转或负载不均。
addShard 后数据不会自动流入新分片
这是最常被忽略的前提。执行 sh.addShard("shard04/mongo04:27018") 只是把新分片注册进集群元数据，mongos 知道它存在了，但已有 chunk 不会自动重分布——除非满足两个条件：balancer 正在运行，且当前分片间 chunk 数量差异超过阈值（默认 8 个）。
- 检查均衡器是否开启：
sh.getBalancerState()，关闭时需先sh.setBalancerState(true) - 查看 chunk 分布：
sh.status()中每个 shard 的chunks行，对比最大/最小值 - 若差异不足阈值，即使有新分片，
balancer也不会启动迁移
多级扩容 ≠ 连续 addShard，必须控制节奏
一次性添加多个分片（如 3 个）容易导致 balancer 过载、迁移队列堆积、主从延迟飙升，甚至引发 Failed to route to shard for transaction 错误。
- 生产环境建议每次只加 1 个分片，等待
sh.status()显示 chunk 均匀（方差 balancer 日志无活跃 moveChunk）后再加下一个 - 可通过
sh.startBalancer({maxTimeMS: 3600000})限制单次均衡耗时，防无限阻塞 - 添加前确认新分片已部署为副本集（非单节点），且
shardsvr模式启动，否则addShard会拒绝
新分片长期“零数据”的常见原因
即使均衡器开着，你仍可能看到新分片的 docs 和 chunks 都是 0 ——这不是命令失败，而是数据分布逻辑卡住了。
- 分片键选择不当：例如用
_id（ObjectID）范围分片，新插入数据天然落在最大值区间，老分片持续接收写入，新分片永远等不到“边界” - chunk 过大未拆分：如果集合尚未触发自动拆分（
initialSplit或写入量不足），整个集合就只有 1 个 chunk，无法跨分片分配 - 手动禁用了自动拆分：
sh.disableAutoSplit("db.coll")未恢复，会导致 chunk 固化 - 解决办法：对目标集合强制预拆分，例如
sh.splitAt("db.coll", {_id: ObjectId("...")})，或插入测试数据触发拆分
真正可控的“多级”动作在迁移层
想让数据按计划流入指定分片（比如按时间分区把 2026Q2 数据定向到 shard04），addShard 不够用，得靠 moveChunk + zone。
- 先定义 zone：
sh.addTagRange("db.coll", {ts: MinKey}, {ts: ISODate("2026-04-01")}, "q1_2026") - 绑定分片与 zone：
sh.addShardToZone("shard03", "q1_2026") - 此时再执行
sh.moveChunk("db.coll", {ts: ISODate("2026-03-15")}, "shard04")，才能确保 chunk 落入目标分片 - 注意：
moveChunk是阻塞操作，大 chunk 迁移期间对应 chunk 不可写，需避开业务高峰
多级扩容的复杂点不在命令本身，而在于 chunk 生命周期管理——拆分、迁移、合并三者如何协同。很多团队卡在“加了分片但数据不动”，本质是把 addShard 当成了“扩容开关”，忽略了 MongoDB 数据流动依赖的是分片键连续性、chunk 边界可切性、以及均衡器对不均衡的敏感度。这三个条件缺一不可。
