如何调整MongoDB的Chunk大小_sh.settings配置与数据迁移频率的平衡

chunksize不能设太小，否则会因频繁分裂和迁移导致路由表更新压力大、config server元数据过载及查询延迟毛刺；默认64mb已平衡开销与均衡性，仅在明确小粒度数据或历史不均时才调整。

chunkSize 为什么不能设太小？ mongodb 的分片集群里，chunkSize 默认是 64MB，它不是“越小越均匀”就越好。设成 16MB 甚至 1MB，短期看数据分布更细，但会立刻触发两个连锁反应：一是 mongos 路由表更新变频繁，二是 config server 上的元数据压力陡增。特别是写入密集场景，每个 chunk 满了就分裂，分裂又触发迁移，而迁移本身要锁 chunk、复制数据、更新 config 集合——这些操作在高并发下会卡住路由决策，导致查询延迟毛刺明显。

• 小于 32MB 的 chunkSize 在多数业务中属于过早优化，除非你明确知道单个 shard 上有大量
• 修改后不会立即重分，已有 chunk 保持原大小，只对后续分裂生效；想快速重分布得手动 splitAt() 或 moveChunk()
• sh.setBalancerState(false) 必须先关，否则自动均衡可能和你的手动调整冲突

怎么安全改 chunkSize？ 改的是集群级配置，不是某个集合或 shard 的局部设置。执行位置必须是连接到 mongos 的 shell（不是 config server 或 shard node），且需要 clusterManager 权限。

• 连接任意 mongos，运行：

  sh.settings.updateOne({ _id: "chunksize" }, { $set: { value: 128 } }, { upsert: true })

• 数值单位是 MB，只接受整数，比如 128 表示 128MB
• 修改后不报错 ≠ 生效，用 sh.settings.find() 确认返回 { "_id" : "chunksize", "value" : 128 }
• 不需要重启任何进程，但新 chunk 分裂从下次满额开始才按新值计算

迁移频率太高？先看是不是 chunk 太碎，而不是急着调 balancer 自动均衡器（balancer）每 10 分钟检查一次 chunk 分布，但它只在“某 shard 的 chunk 数比平均值高出 2 个以上”时才触发迁移。如果你看到 moveChunk 日志高频出现，大概率是 chunkSize 设得太小 + 数据分布倾斜（比如时间戳做 shard key），而非 balancer 本身太激进。

• 查当前各 shard chunk 分布：

  sh.status().shards.map(s => ({ name: s._id, chunks: s.chunks }))

• 如果某 shard chunk 数远高于其他（比如 500 vs 80），优先检查该 shard 上是否有未打散的大范围查询或写入热点
• 关闭 balancer 后手动迁移更可控：sh.moveChunk("db.coll", { shardKey: value }, "targetShard")，但注意目标 shard 磁盘余量和 oplog 延迟
• balancerStart/balancerStop 是临时开关，不影响 chunkSize 配置本身

真实场景里，什么情况下值得动 chunkSize？ 绝大多数线上集群根本不需要改，默认 64MB 平衡了迁移开销和负载均衡能力。真要调，只在两种情况成立：

• 新建集群初期，已知业务数据天然粒度极小（如 iot 设备每秒一条记录，shard key 是设备 ID + 秒级时间戳），且单设备数据日增
• 历史遗留集群 chunk 严重不均，又不想停写做全量 dump/reload，可配合 splitVector 先把大 chunk 拆细，再调大 chunkSize 防止继续碎裂

改完别只盯着迁移日志，重点看 config server 的 config.changelog 写入速率和 mongos 的 route 延迟指标——这两处才是失衡最先暴露的地方。