MongoDB 6.0开启预分片技术提升批量写入速度

先纠正一个常见误区：许多开发者误以为 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 连接后执行。
• 时间序列集合不支持重新分片，写入前务必确认集合类型。