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 字段定位具体哪条出错。
- 适用场景：导入脏数据、补录历史记录、幂等性写入（如
updateOnewithupsert: true） - 不适用场景：强顺序依赖操作（如连续编号生成）、金融类事务型更新
- 注意：即使
ordered: false，每个操作仍受单分片写锁限制，无法突破单分片吞吐上限
容易被忽略的底层约束
MongoDB 6.0 的 bulkWrite() 在分片环境下实际受限于更底层机制：
- writeConcernMajorityJournalDefault 必须为
true才能支持安全的 majority 写关注，否则分片间日志同步可能丢失 - retryWrites 默认开启，但仅对网络闪断或 primary 切换有效；对分片路由错误、键冲突、磁盘满等业务错误不重试
- 无法在 Atlas UI 中直接调用
bulkWrite()—— 必须通过驱动或 mongosh 连接后执行 - 时间序列集合不支持重新分片，bulkWrite 写入前务必确认集合类型
