bulkWrite比insertMany更可控，因其支持混合操作、细粒度writeConcern与upsert配置，并可通过ordered:false实现无序并行执行，避免单点失败中断及写入瓶颈。

bulkWrite 是 MongoDB 批量写入的底层接口，比 insertMany 更灵活、更可控，尤其在副本集或分片集群中能显著提升吞吐量——但前提是用对参数、避开常见陷阱。

bulkWrite 为什么比 insertMany 更适合高并发写入

insertMany 实际是 bulkWrite 的封装，它默认 ordered: true，遇到第一条失败就中断整个批次；而 bulkWrite 允许显式控制 ordered: false，让驱动把操作分发到多个节点并行执行。在副本集里，这能绕过单点 oplog 写入瓶颈；在分片集群中，mongos 可同时向多个分片发包。

• 混合操作支持：一个 batch 里可混用 insertOne、updateOne、deleteMany，无需拆成多次调用
• writeConcern 可逐条指定：比如日志类数据用 { w: 1 }，订单类用 { w: "majority" }，避免全局降级
• upsert 行为可单独开关：不必统一设 upsert: true，而是按需在每个 updateOne 里传

ordered: false 不是万能加速器，得看场景

设 ordered: false 后，bulkWrite 确实不因某条失败而停，但副作用也很直接：错误顺序不可预测、返回结果里 writeErrors 和 writeConcernErrors 混在一起、部分成功时难定位哪几条没写进去。

• 适合埋点、日志、IoT 数据等“丢了也不致命”的场景
• 不适合强一致性要求的业务，比如账户余额更新——此时必须用 ordered: true + 重试逻辑
• 分片集群下效果最明显；单机或主从结构里提升有限，甚至可能因网络竞争变慢

批量大小和 writeConcern 怎么配才不翻车

批量太大（如 >1000 条）容易触发 WiredTiger 内存压力或超时；太小（如

• 推荐每批 100–500 条，按文档平均大小动态调整：大文档选下限，小文档选上限
• 务必显式传 writeConcern: { w: 1 }，别依赖默认——生产环境常被配置覆盖，导致意外等待 majority
• 避免在同一批里混用高代价操作：比如 updateOne（需查索引+读文档）和 insertOne（纯追加）一起跑，会拉长整体耗时
• 如果用了 w: "majority"，确认所有从节点 oplogSize ≥24 小时变更量，否则写入会持续阻塞

bulkWrite 在分片集群里的特殊注意事项

分片环境下，bulkWrite 的性能表现高度依赖分片键设计和预分配策略。不是所有“无序+大批量”都能自动摊平到各分片。

• 空集合必须预拆分：否则初始所有写入都打到同一个 chunk，变成单分片瓶颈
• 避免单调递增分片键：比如时间戳、自增 ID，会导致新数据总写入最后一个 chunk；可用 ObjectId 二进制反转或字段交换打散
• 跨数据库/集合写入需 MongoDB 8.0+，用 db.adminCommand({ bulkWrite: 1, ... })，旧版本只能单集合调 db.collection.bulkWrite()

真正影响 bulkWrite 效果的，往往不是语法写得对不对，而是 writeConcern 是否按业务分级、批量是否贴合 WiredTiger 缓存特性、以及分片键是否天然具备离散性——这些地方一踩坑，再怎么调 ordered 都白搭。