先用三步验证是否真存在分布偏差：运行sh.status(true)看chunks数量及jumbo标记；执行db.admincommand({balancerstatus:1})确认mode为full且inbalancerround为true；对热点集合单独查db.collection.getsharddistribution()暴露单集合倾斜。
分片集群数据不均衡不是配置没生效，而是负载均衡器在“有选择地不干活”——它只对可迁移的普通块起作用，对 jumbo 块、单值分片键块、未启用均衡的集合或刚加进来的空分片完全无感。
怎么快速确认是不是真的不均衡
别急着调参数，先用三步验证是否真存在分布偏差：
- 运行
sh.status(true)，重点看每个分片的chunks数量和是否标有jumbo - 执行
db.adminCommand({ balancerStatus: 1 })，确认mode是full且inBalancerRound为true - 对热点集合单独查分布：
db.collection.getShardDistribution()，比sh.status更细粒度，能暴露单个集合的倾斜
常见假象：某个分片 CPU 高但 chunks 数正常——那大概率是查询倾斜（比如全表扫描或未命中索引），不是数据分布问题。
为什么 sh.splitAt 执行后还是不迁移
sh.splitAt 只负责切块，不触发迁移；迁移由负载均衡器按阈值自动发起，且受制于当前迁移队列和锁状态。
- 切完必须等下一个均衡轮次，可通过
sh.startBalancer()强制唤醒（但别频繁调） - 如果目标 chunk 已被标记
jumbo，sh.splitAt会静默失败，需先用sh.removeJumbo清除标志（MongoDB 4.4+）或手动 split + moveChunk 组合操作 - 检查配置服务器日志是否有
cannot move chunk: failed to acquire lock，说明 config server 主节点选举刚发生，需等待 30–60 秒再试
分片键导致的隐性不均衡怎么识别
哈希分片不等于绝对均匀——当分片键值本身分布极偏（如大量 null、空字符串或固定值），哈希后仍会聚到同一 chunk。
- 用
db.collection.aggregate([ { $group: { _id: "$shardKeyField", count: { $sum: 1 } } }, { $sort: { count: -1 } }, { $limit: 5 } ])查前 5 个高频值 - 若某值占比 >20%，且该集合 chunk 数极少（如
nchunks: 1），基本锁定为低基数分片键 - 单调递增字段（如
timestamp、order_id）会导致写入全部打向最后一个 chunk，即使哈希也难缓解，此时应改用hashed分片键或加随机后缀
真正棘手的是那些“看起来均匀、实际不均”的场景：比如分片键是 {userId: 1, type: 1}，但 90% 的 type 都是 "default"，结果所有 userId 全挤在同一个 type 范围里——这种必须靠聚合分析暴露，sh.status 看不出来。
