直接对大集合启用分片会触发自动chunk迁移，导致写入阻塞、主从延迟飙升甚至LockTimeout错误；应先对空集合预分片（如numInitialChunks=4096），再导入数据，并关闭balancer确保稳定。
直接对大集合启用分片会触发自动 chunk 迁移，导致写入阻塞、主从延迟飙升甚至 LockTimeout 错误
这不是配置问题，而是 MongoDB 分片机制的固有行为：当对已有亿级文档的集合执行 sh.shardCollection() 时，系统必须边扫描数据、边切分 chunk、边迁移——整个过程锁 config server、压 mongos、拖慢所有写入。线上环境常因此出现 InterruptedDueToReplStateChange 或 NotMasterNoSlaveOk，不是超时设置太短，是底层根本扛不住。
预分片必须用空集合 + numInitialChunks 参数手动创建初始 chunk
核心是绕过自动拆分逻辑，让 chunk 在数据写入前就“就位”。操作必须按顺序来：
- 先执行
sh.enableSharding("db_name")启用数据库分片 - 再用
sh.shardCollection("db_name.coll_name", {"shard_key": 1}, {"numInitialChunks": 4096})创建空集合并预分配 chunk（numInitialChunks必须是 2 的幂，4096 是生产常用值；8192 更稳妥，但别超过 16384，否则 config server 元数据压力陡增） - 立即运行
sh.status()查看各 shard 的 chunk 数量是否接近均等；若偏差大，需在无写入窗口内用sh.splitAt()和sh.moveChunk()手动调平
分片键类型决定预分片是否真正有效
哈希分片键（如 {"user_id": "hashed"}）天然适配预分片：numInitialChunks 会把哈希空间（0–2⁶⁴−1）等分，chunk 落点天然分散。但范围分片键（如 {"region": 1, "created_at": 1}）不保证数据均衡——哪怕你预分配了 4096 个 chunk，只要新数据集中在某个 region 或时间区间，所有写入仍会打到同一组 chunk 上，形成热点 shard。
所以：
- 优先选哈希分片键，预分片效果可预期
- 若必须用范围分片键，
numInitialChunks只控制初始 chunk 数量，不解决分布问题；得配合sh.splitAt()按业务维度主动切分，例如先按region值 split 出 100 个一级 chunk，再为每个 region 内的created_at做二级切分 - 单调递增字段（如
_id或时间戳）绝对不要单独作范围分片键，这是预分片失效的最常见原因
导入数据前必须关闭 balancer 并确认路由层稳定
即使 chunk 已预分配且分布均匀，mongorestore 或批量 insertMany() 仍可能因 write concern 设置、网络抖动或 chunk 大小触发隐式分裂和迁移。此时 balancer 若开着，会和导入任务争抢资源，极易卡在 writeConcernTimeout 状态。
安全做法是：
- 导入前执行
sh.setBalancerState(false) - 确保所有 mongos 进程已加载最新路由表（可通过
db.runCommand({getShardVersion: 1})验证） - 导入完成后再开启 balancer，并用
sh.waitForBalancer()等待平衡结束
预分片不是“设完参数就完事”，它把问题从“实时迁移”转移到“预分配合理性”和“导入节奏控制”上——这两个环节漏掉任何一个，亿级数据照样卡住。
