MongoDB 6.0 Balancer 不再依赖Chunk数量而改用集合数据大小（差异超384 MB）触发迁移，结合128 MB默认chunkSize、后台化split及严格activeWindow控制，实现更真实均衡与业务零感知。
6.0 Balancer 迁移不再依赖 Chunk 数量判断
旧版本（5.0 及以前）Balancer 的核心逻辑是“数 Chunk”，一旦某 Shard 上 Chunk 数超过阈值（如 5.0 是固定阈值 1），就触发 moveChunk。但 Chunk 大小不均，会导致磁盘空间严重失衡——比如一个 128 MB 的大 Chunk 和十个 1 MB 的小 Chunk，数量一样，空间差百倍。
MongoDB 6.0 改为直接监控每个 Shard 上**同一集合的实际数据大小**，当差异超过 384 MB（即 3 × 默认 chunkSize）才迁移。这避免了“数得匀、存得歪”的假均衡，迁移目标更真实，也更少无谓调度。
- 迁移依据从逻辑单位（
Chunk）转向物理单位（字节），业务感知更准 -
getShardDistribution()成为唯一可信的均衡检查命令，sh.status()中的 Chunk 计数已不可信 - 升级后看到某 Shard 只剩 1 个 Chunk，不是故障，是新策略下自动合并+按需迁移的结果
6.0 默认 chunkSize 翻倍，显著降低迁移频次
6.0 将默认 chunkSize 从 64 MB 提升到 128 MB，直接影响迁移行为：
- 同样数据量下，Chunk 总数减半 → 需要迁移的 Chunk 数量天然减少
- 单次
moveChunk携带的数据更多，网络和锁开销摊薄，整体吞吐更高 - Chunk 路由表条目变少，
mongos查询路由更快，元数据压力下降
注意：chunkSize 是集群级配置，修改需通过 sh.setBalancerConfig({ chunkSize: 128 })，且仅对后续新 Chunk 生效；已有 Chunk 不会自动重切。
6.0.3 起 split 操作完全后台化，业务线程零感知
在 5.0 及更早版本中，当写入触发 Chunk 分裂（split）时，是由用户请求线程同步完成的——也就是说，你发一条 insert，可能卡在等待分裂完成上，尤其在高并发写入场景下，延迟毛刺明显。
6.0.3 开始，split 由 Shard 上独立的后台线程执行，用户线程只管写，分裂异步推进。这意味着：
- 写入 P99 延迟更稳定，不再被分裂阻塞
- 迁移前的分裂准备（如为均衡腾出空 Chunk）不再拖慢业务
- 配合更大的
chunkSize，分裂频率本身也大幅下降
迁移任务调度更克制，窗口外不排队、不中断
6.0 对 activeWindow 的实现更严格：窗口外不仅不发起新迁移，也不会把倾斜数据加入待处理队列。而旧版本有时会在窗口外累积迁移需求，等窗口一开就集中爆发，导致 CPU 和网络瞬间打满。
验证是否生效，看 sh.status() 输出中 balancer 字段下的 activeWindow 是否正确显示，且 inBalancerRound 为 false（窗口外）时，config.migrationTasks 集合应为空。
容易被忽略的是：即使窗口设对了，如果之前有积压任务没清完（db.getSiblingDB("config").migrationTasks.find().count() > 0），迁移仍会持续 —— 这不是新版本问题，而是历史任务未收尾。平滑的前提，是每次维护后都确认迁移真正结束。
