真正反映Balancer迁移进度的是moveChunk（或6.0+的moveRange）操作状态和config.shards中数据分布变化；sh.isBalancerRunning()返回true表示正执行迁移，db.currentOp可查实时任务，getShardDistribution命令验证实际数据均衡效果。
直接看 sh.isBalancerRunning() 和迁移日志，但真正反映进度的是 moveChunk 操作状态和 config.shards 集合里的数据分布变化。
查 Balancer 是否正在执行迁移任务
很多人误以为 sh.getBalancerState() 返回 true 就代表“正在搬数据”，其实它只说明 Balancer 功能已启用。真正干活的状态得用：
-
sh.isBalancerRunning()—— 返回true表示当前有moveChunk（或 6.0+ 的moveRange）正在执行 -
sh.status()输出中关注currently-running: true字段，它和isBalancerRunning()语义一致 - 如果返回
false，不代表没任务，可能是刚完成一个 chunk、正等待下一轮触发条件（比如差值再次超阈值）
看实际迁移中的 chunk/range 进度
Balancer 不会暴露“已迁 127/843 个 chunk”这种进度条，但你可以从 config server 上查实时操作：
- 连接到 config server 主节点（不是 mongos），执行：
use config<br>db.locks.findOne({ _id: "balancer" })—— 若state为2，表示 Balancer 正持有锁并活跃；who字段会显示当前执行迁移的 mongos 或 config 节点 - 查正在进行的迁移：
db.currentOp({ "secs_running": { $gt: 5 }, "ns": "config.moveChunk" })—— 可看到具体哪个集合、哪个 shard 正在 move、源/目标分片名、已运行秒数 - 6.0+ 版本注意：操作名是
config.moveRange，不是moveChunk，逻辑单位是 range（按数据大小而非 chunk 数量）
验证迁移效果：别只盯 chunk 数，要看真实数据分布
MongoDB 6.0+ 后，sh.status() 显示的各 shard chunk 数可能严重不均——这是正常现象，因为 Balancer 已转向按集合数据大小均衡。真正该查的是：
-
db.runCommand({ getShardDistribution: "your_db.your_collection" })—— 直接返回每个 shard 上该集合的文档数、大小（bytes）、片键范围，这才是你关心的“是否搬到位了” - 对比
sh.status()中各 shard 的dataSize字段（需开启verbose模式）或聚合config.chunks统计各 shard 的size总和 - 注意：如果某 shard 的
dataSize比其他 shard 高出 >384 MB（三倍默认 chunk size），说明 Balancer 还没完成本轮均衡，或被窗口期/stop 状态阻断
最容易被忽略的是：Balancer 迁移本身不报错也不打日志到 mongos，默认只记在 config server 主节点的 mongod.log 里，关键词是 moveChunk 或 moveRange。如果你没定期扫 config 日志，就等于在盲操作。
