分片集群 Chunk 分布不均导致热点时，最推荐的处理方向是启用自动平衡器或手动迁移 Chunk，适用场景为 MongoDB 等支持片键范围的数据库，最重要的风险边界是迁移期间可能增加集群负载。
先说结论：解决 Chunk 分布不均的核心是触发数据迁移，使各分片负载趋于一致，但需避免在业务高峰期执行。
- 先定位：通过 sh.status() 确认 Chunk 分布差异及热点片键范围。
- 先做：启用自动平衡器或使用 sh.moveChunk() 手动迁移热点数据。
- 再验证：观察集群负载指标及 Chunk 分布状态是否回归均衡。
命令速用版
以下命令基于 MongoDB Shell 环境，用于查看状态和执行迁移。
// 查看分片集群状态及 Chunk 分布
sh.status()
// 启用自动平衡器
sh.startBalancer()
// 手动迁移 Chunk（需指定命名空间、片键范围和目标分片）
sh.moveChunk("ns", { key: "value" }, "targetShard")为什么会这样
Chunk 分布不均通常由片键选择不当或写入模式倾斜导致。分片集群将数据划分为 Chunk 并分布在不同分片上，当特定范围的写入量远超其他范围时，承载该范围 Chunk 的分片会成为热点。
分步处理
步骤 1：确认分布状态
在 mongos 实例执行 sh.status()，检查 chunks 字段下各分片的 Chunk 数量差异。如果某分片 Chunk 数量显著多于其他分片，或特定范围请求量集中，确认为分布不均。
步骤 2：启用自动平衡
检查平衡器状态，若已停止则执行 sh.startBalancer()。平衡器会在后台自动迁移 Chunk，无需人工干预，但迁移速度受阈值控制。
步骤 3：手动紧急迁移
若自动平衡无法满足时效要求，使用 sh.moveChunk() 将热点 Chunk 迁移至负载较低的分片。操作前需确认目标分片有足够存储空间。
步骤 4：优化片键策略
若热点由片键单调递增导致，长期方案是更换片键或使用哈希片键。注意更换片键通常需要重新导入数据，需评估停机成本。
怎么验证是否生效
再次执行 sh.status() 对比 Chunk 数量分布。监控分片节点的 CPU、磁盘 IO 及请求延迟，确认热点分片负载下降，其他分片负载上升且整体平稳。
常见坑
- 迁移期间锁竞争：手动迁移大块数据可能占用集群资源，避免在业务高峰期执行 sh.moveChunk()。
- 片键不可逆：MongoDB 不支持直接修改已有数据的片键，若片键设计错误，平衡数据只能缓解无法根除。
- 平衡器阈值：默认迁移阈值可能反应滞后，紧急情况下需手动干预。
常见问题
分片集群平衡器会影响业务性能吗？
会有轻微影响。平衡器迁移数据时会占用网络和磁盘 IO，但 MongoDB 设计为后台运行，通常不会阻塞正常读写。
能否直接修改已有数据的片键？
不能。MongoDB 不支持直接修改文档的片键字段，如需更换片键通常需要导出后重新导入集群。
Chunk 大小可以调整吗？
可以。通过 config.settings 集合调整 chunksize 参数，但公开资料中没有看到可靠的量化数据表明调整大小能直接解决热点，需结合业务场景测试。
参考来源
- MongoDB Official Documentation - Sharding: https://www.mongodb.com/docs/manual/sharding/
- MongoDB Official Documentation - sh.moveChunk(): https://www.mongodb.com/docs/manual/reference/method/sh.moveChunk/