不能直接对已有大集合启用分片，因为会触发自动chunk迁移，导致写入阻塞、主从延迟飙升、config server过载及locktimeout等错误；空集合预分片可手动创建全范围初始chunk并均匀分布，避免实时迁移。
为什么不能直接对已有大集合启用分片
直接对已存大量数据的集合执行 sh.enableSharding() 和 sh.shardCollection() 会触发 MongoDB 自动迁移 chunk 的过程，而这个过程在数据量大、负载高时极易导致：写入阻塞、主从延迟飙升、config server 压力过载，甚至出现 LockTimeout 或 InterruptedDueToReplStateChange 错误。更关键的是，自动拆分依赖当前数据分布和 chunk 大小策略，无法控制初始分片键值范围，后续再平衡代价极高。
空集合预分片的核心操作步骤
本质是绕过自动 chunk 拆分，手动创建覆盖全范围的初始 chunk，并确保每个 chunk 都落在目标 shard 上——这样后续导入数据时，路由层能立即定位到正确节点，不触发实时迁移。
- 先调用
sh.enableSharding("db_name")启用数据库分片 - 用
sh.shardCollection("db_name.coll_name", {"shard_key": 1}, {"numInitialChunks": 4096})创建空集合并预分配 chunk（numInitialChunks必须是 2 的幂，推荐 4096 或 8192，避免后期频繁分裂） - 立即执行
sh.status()确认 chunk 已均匀分布在各 shard 上；若不均，用sh.splitAt()和sh.moveChunk()手动调整（注意：必须在无写入时操作） - 确认分片状态稳定后，再通过
mongorestore --drop或批量insertMany()导入数据
分片键选择与预分片范围对齐的关键点
预分片只对分片键有明确范围的场景有效。如果分片键是单调递增的 _id 或时间戳，chunk 很容易全部落到同一个 shard（即“热点 shard”），即使预分配了 4096 个 chunk，实际数据仍集中在末尾几个 chunk。
- 优先选哈希分片键：
{"user_id": "hashed"}，MongoDB 会自动将哈希空间（0–2^64-1）等分，天然适配预分片 - 若必须用范围分片键（如
{"region": 1, "created_at": 1}），需配合sh.splitAt()主动切分，例如按region值预先划分 100 个区间，再为每个区间内created_at设置子范围 -
numInitialChunks参数对哈希分片有效，对范围分片仅影响初始 chunk 数量，不保证数据均衡——这点常被忽略
导入阶段避坑：别让 bulk 写入冲垮路由层
即使预分片完成，单线程大批量插入仍可能因 write concern 或网络抖动导致部分 chunk 迁移卡住，表现为 writeConcernTimeout 或 NotMasterNoSlaveOk。
- 导入前关闭 balancer：
sh.stopBalancer()，等全部数据导入完成、校验一致后再开启 - 使用
mongorestore --numInsertionWorkersPerCollection=8 --batchSize=24000控制并发和批次大小（具体数值依 shard 内存和磁盘 IO 调整） - 避免在导入期间执行
sh.addShard()或sh.removeShard()，这些操作会强制刷新 config server 元数据，干扰 chunk 路由 - 导入后务必运行
db.coll_name.stats({scale: 1})核对各 shard 的count和size，再用sh.status()看 chunk 分布是否符合预期
真正难的不是跑通命令，而是预判分片键行为、提前规划 chunk 范围、并在导入窗口期稳住 config server 和所有 shard 的元数据一致性——这些环节出问题，日志里不会报错，但数据会悄悄倾斜或写入变慢。
