预分片必须在写入前用sh.splitAt()对空集合按哈希空间等分切点，否则千万级导入会卡死在首个shard；需配合bulkWrite+unordered才能实现并发路由与均匀写入。
不做预分片，千万级导入基本卡死在第一个 shard 上——这不是配置问题，是 MongoDB 的 chunk 初始化机制决定的。
为什么 sh.splitAt() 必须在写入前执行
一旦集合里有任意一条文档，sh.splitAt() 就可能失败或被 balancer 中断。MongoDB 不允许对已有数据的 chunk 边界做“插队式”拆分；它只接受在空集合上预先规划好 chunk 范围。你看到 sh.status() 里 chunks 行只显示 1 个、且全部落在 shard0000，说明已经错过窗口期。
- 检查方式：连接 mongos 后运行
sh.status()，看chunks行是否为 1，以及balancer状态是否为OK（不是Running或Stopping） - 补救成本高：已有数据时强行 split + moveChunk 容易触发迁移冲突，且无法保证后续写入立刻分散
- 哈希分片键（如
{_id: "hashed"}）比范围分片更适配预分片，因为边界值可精确计算，无热点偏移风险
怎么用 sh.splitAt() 算出并切出 N 个初始 chunk
以 8 个 shard 为例，哈希空间是 64 位有符号整数（-2^63 到 2^63-1），总跨度为 2^64。每份 chunk 宽度 = 2^64 / 8 = 0x2000000000000000，切点就是从 0x2000000000000000 开始，每次加这个值，直到 0xE000000000000000（共 7 个切点）。
- Python 快速生成切点（注意用
NumberLong格式）：for i in range(1, 8): print(hex(i * 0x2000000000000000))
- 逐条执行：
sh.splitAt("db.coll", {_id: NumberLong("0x2000000000000000")}) - 执行完立刻
sh.status()验证：确认chunks总数为 8，且每个 shard 下至少有 1 个 chunk（不是全堆在同一个 shard）
bulkWrite + unordered 才能让预分片真正起效
预分片只是铺好了路，如果客户端还串行发写请求，mongos 仍可能把请求都打到同一个 shard 上。必须配合无序批量写入，才能触发 mongos 并行路由。
- 驱动层设置：
ordered: false（Node.js、PyMongo、Java Driver 均支持） - 命令行工具不适用：
mongoimport默认是有序写入，且无法控制ordered参数；它底层调用的是单文档插入，不是bulkWrite - 性能差异明显：实测同样 500 万文档，
bulkWrite+ordered: false比mongoimport快 3–5 倍，CPU 利用率在所有 shard 均匀分布 - 错误处理要自己兜底：无序模式下某条失败不影响其余，但你需要检查返回结果里的
writeErrors字段
导入后要不要 touch 数据预热
预热对首次查询延迟敏感的场景有用，但对纯写入优化无效。如果你刚导入完就立刻跑大量聚合或索引构建，db.runCommand({touch: "coll", data: true, index: true}) 能减少磁盘 IO 颠簸。
- 只对高频访问的集合做，别全库 touch；内存不足时老数据会被挤出，反而增加 page fault
- 确认生效：执行后看返回的
millis字段，data和indexes都应有毫秒级耗时，否则说明文件没加载成功 - 它不解决写入瓶颈，只是缓解后续读压力；写入卡顿根源永远在 chunk 分布和写入并发策略
最容易被忽略的是：预分片切点必须严格按哈希空间等分，少一个切点，就少一个初始 chunk，剩余数据仍会堆积在最后一个未 split 的 chunk 上——哪怕你算错了 1 个 bit，整个预分片就失效了。
