先纠正一个常见误区：许多开发者误以为 MongoDB 6.0 推出的“Bulk Write 预分片技术”能够自动将数据写入正确位置。实际上，bulkWrite() 本身并不具备预分片功能——它只是一个批量发送操作的工具。真正决定大批量写入速度的核心，在于你是否提前完成了分片键设计、集合分片以及数据均匀分布。换句话说，bulkWrite() 不会替你分片，也无法绕过分片瓶颈，它只负责将多个操作打包发送，但数据往哪里写、路由是否通畅，完全取决于分片配置。
因此，如果你在分片集群中使用 bulkWrite() 发现速度上不去，甚至出现错误，原因大概率是分片准备不足。下面详细分析几个关键要点。
为什么 bulkWrite() 在分片集群中可能变慢甚至失败
在尚未合理分片的集合上执行 bulkWrite()，所有操作仍然会全部路由到主分片——相当于流量全部挤在一个入口，单点瓶颈立刻显现。反之，如果操作跨多个分片，但分片键选择不当，会触发大量 scatter-gather 查询，写入延迟飙升，严重时还可能因 writeConcern 超时导致整个 batch 失败。
- 典型错误：返回
WriteResult({ "nInserted" : 0, "writeErrors" : [ { "index" : 0, "code" : 13, "errmsg" : "not master" } ] })或长时间无响应。 - 根本原因只有两个：操作被路由到非主分片，或者分片键基数过低、分布不均导致数据倾斜。
- 设置
ordered: false可以缓解部分失败传播，但治标不治本——底层路由和负载不均的问题依然存在。
真正有效的提速组合：分片准备 + bulkWrite 配置
要想让 bulkWrite() 发挥并行写入的优势，必须提前做好分片初始化。具体建议如下：
- 确认集合已启用分片：执行
sh.enableSharding("db_name")与sh.shardCollection("db_name.collection", { "shard_key": 1 })。 - 分片键需要满足三个条件：高基数、写入均匀、常用于查询。应避免使用
_id（ObjectId 时间戳前缀容易产生热点）或单调递增字段。 - 批量大小建议控制在 100–1000 条/次
bulkWrite()调用。数据量过大容易触发内存或超时，过小则网络开销占比过高。 - 设置
writeConcern: { w: "majority", j: true }时需要权衡持久性与吞吐量。压测阶段可临时使用{ w: 1 }先摸清基线性能。
ordered: false 不等于“跳过错误继续”，而是控制失败传播方式
默认情况下 ordered: true，一旦某个操作失败（如唯一键冲突），后面的操作全部跳过。改为 ordered: false 后，其余操作可以继续执行，但返回结果中你需要自行检查 writeErrors 字段来定位具体问题。
- 适用场景：导入脏数据、补录历史记录、幂等性写入（如
updateOne配合upsert: true）。 - 不适用场景：强顺序依赖的操作（如连续编号生成）以及金融类事务型更新。
- 注意：即使使用
ordered: false，每个操作仍然受单分片写锁限制，无法突破单个分片的吞吐上限。
容易被忽略的底层约束
MongoDB 6.0 的 bulkWrite() 在分片环境下还受到一些底层机制的限制：
writeConcernMajorityJournalDefault必须为true，否则安全的 majority 写关注无法启用，分片间的日志同步可能丢失数据。retryWrites默认开启，但仅对网络闪断或 primary 切换有效。分片路由错误、键冲突、磁盘满等业务错误不会重试。- 在 Atlas UI 中无法直接调用
bulkWrite()，必须通过驱动或 mongosh 连接后执行。 - 时间序列集合不支持重新分片，写入前务必确认集合类型。
