MongoDB 6.0如何提升大批量数据写入速度：开启Bulk Write预分片技术

bulkWrite() 无预分片功能，提速关键在于提前完成分片键设计、集合分片和数据均匀分布；未合理分片时易导致单点瓶颈或scatter-gather延迟，需配合正确分片配置与bulkWrite参数优化。

bulkWrite() 本身不提供“预分片”功能，MongoDB 6.0 也没有叫“Bulk Write预分片技术”的东西——这是常见误解。真正影响大批量写入速度的关键，在于是否提前完成**分片键设计 + 集合分片 + 数据均匀分布**，而 bulkWrite() 只是把多个操作打包发给服务端，它不会自动帮你分片、也不会绕过分片瓶颈。

为什么 bulkWrite() 在分片集群里可能变慢甚至失败

在未合理分片的集合上执行 bulkWrite()，所有操作仍会路由到同一个分片（即主分片），形成单点写入瓶颈；若操作跨多个分片但缺少合适分片键，会导致大量 scatter-gather 查询，写入延迟飙升，甚至触发 writeConcern 超时。

• 典型错误现象：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 with upsert: true）
• 不适用场景：强顺序依赖操作（如连续编号生成）、金融类事务型更新
• 注意：即使 ordered: false，每个操作仍受单分片写锁限制，无法突破单分片吞吐上限

容易被忽略的底层约束

MongoDB 6.0 的 bulkWrite() 在分片环境下实际受限于更底层机制：

• writeConcernMajorityJournalDefault 必须为 true 才能支持安全的 majority 写关注，否则分片间日志同步可能丢失
• retryWrites 默认开启，但仅对网络闪断或 primary 切换有效；对分片路由错误、键冲突、磁盘满等业务错误不重试
• 无法在 Atlas UI 中直接调用 bulkWrite() —— 必须通过驱动或 mongosh 连接后执行
• 时间序列集合不支持重新分片，bulkWrite 写入前务必确认集合类型