最能反映分片集群是否正常的关键字段是：shardingVersion 是否一致、config server 是否全部在线、各 shard 的 state 是否均为 1（active）；state 为 0 或缺失表示分片脱网但未剔除，可能导致写入部分失败。
sh.status() 输出里哪些字段最能反映分片集群是否正常
sh.status() 是 MongoDB 分片集群最直接的健康快照，但它输出信息密集，关键指标容易被忽略。真正影响可用性的不是“有没有报错”，而是 shardingVersion 是否一致、mongos 连接的 config server 是否全部在线、以及每个 shard 的 state 是否为 1（即 active）。如果任意 shard 的 state 是 0 或缺失，说明该分片已脱网但未触发自动剔除——此时写入可能部分失败，而应用层未必立刻感知。
config server 状态异常时 sh.status() 会静默降级
当 config server 集群中有一个节点宕机（比如三节点 configRS 中挂了一个），sh.status() 仍能执行，但输出顶部的 config server 行可能只显示两个地址，且不报错。这不代表集群健康，而是 mongos 降级为“容忍单点故障”模式运行。此时你必须手动检查：db.adminCommand({replSetGetStatus: 1}) 在 config server 上执行，确认 members[n].stateStr 全是 PRIMARY 或 SECONDARY，没有 RECOVERING 或 ARBITER 混入（ARBITER 在 config server 中是非法角色）。
chunks 分布严重倾斜会拖慢 sh.status() 本身
当某个 shard 上的 chunk 数量远超其他 shard（例如 5000 vs 平均 200），sh.status() 执行时间可能从 2 秒飙升到 40 秒以上——因为它要拉取所有 chunk 元数据并汇总。这不是功能异常，但会掩盖真实问题。可先用以下命令快速探查分布：
db.getSiblingDB("config").chunks.aggregate([{$group: {_id: "$shard", count: {$sum: 1}}}, {$sort: {count: -1}}])
如果最大值超过平均值 3 倍，说明 balancer 可能卡住或 chunk size 设置过小（默认 64MB，小文档场景建议调大到 128–256MB）。
balancer 开关状态和最近活动必须交叉验证
sh.status() 底部会显示 balancer: {"enabled": true, "inBalancerRound": false}，但这只是 mongos 缓存的状态。真实 balancer 是否在工作，要看 config server 上的锁：
db.getSiblingDB("config").locks.find({_id: "balancer"}).pretty()
若 state 是 2（locked）且 who 字段包含 host 和时间戳，说明它正在运行；若 state 是 0 但 enabled 为 true，可能是上次迁移失败后未释放锁，需手动清理（仅限紧急情况，且确保无迁移进行中）。
真正难排查的是跨分片事务或带 $lookup 的聚合在 chunk 边界不一致时的行为——sh.status() 完全不体现这类逻辑层风险，得靠 db.currentOp({secs_running: {$gt: 5}}) 结合 sh.getBalancerWindow() 综合判断。
