MongoDB insertMany批量插入数据高效方法

先给出结论：insertMany 本身并不慢，真正拖慢性能的往往是默认的 ordered: true 设置。一旦中间某条文档插入失败（例如重复键冲突），整个批处理会立即中断，后续文档全部被跳过。很多开发者调试时遇到 BulkWriteError 报错，误以为整批都失败了，实际上只是被“有序模式”截断了。

insertMany 为什么比循环 insertOne 慢？——有序模式是主要瓶颈

说实话，不是 insertMany 本身慢，而是它的默认行为——有序执行（ordered: true）在作祟。一旦中间某条文档出现键冲突等异常，后续所有文档会立即被停止。数据量大时尤其棘手：你以为整批都失败了，其实只是被中断，其余插入结果根本看不到。

常见的错误表现包括：看到 BulkWriteError 报错，但只显示第一条失败原因，其余的都石沉大海；或者数据量一大，耗时远超预期——实际上，问题往往出在未关闭写关注（writeConcern）或连接池调优不足上。

• 关键一招：启用 ordered: false，允许跳过失败项继续执行，特别适合容忍脏数据的场景。
• 写关注别拖后腿：显式设置 writeConcern: { w: 1 } 可避免默认 { w: "majority" } 带来的全局同步等待，性能提升立竿见影。
• 批次大小要克制：单次 insertMany 不要超过 10 万条文档，否则容易触发 BSON 限制（16MB）或内存溢出，得不偿失。

如何避免 BSON 大小限制错误？

insertMany 提交的整个数组会被序列化为一个 BSON 对象，总大小必须控制在 16MB 以内。这不是单条文档的限制，而是整批请求的上限。遇到 Document too large for insert 错误时，必须进行拆分。

实际操作建议：

• 提前量很重要：使用 Buffer.byteLength(JSON.stringify(doc), 'utf8') 预估单条体积，并留出 20% 的余量再计算批次大小，比拍脑袋更可靠。
• 按字节切分更可靠：不要依赖 chunkSize 硬拆，尤其文档长度差异大时，按字节比按条数更准确。
• 流式处理省内存：在 Node.js 中，可以使用 stream.Transform 边读取边分块，避免一次性加载全部数据到内存。

insertMany 后如何获取成功插入的 _id？——正确做法与注意事项

insertMany 返回的 ops 数组虽然与原始输入顺序一致，但只有成功插入的文档包含 _id 字段。如果使用 { ordered: false }，失败项不会出现在 ops 中，你也无法直接通过它定位原数组索引。

正确做法：

• 加个临时标记：插入前为每条文档添加唯一的临时 ID，例如 tempId: Math.random()，失败后从 result.getWriteErrors() 中提取 index 找回原数据。
• 别盲目依赖返回值：如果需要“插入后立即查询新 _id”，不要依赖返回值，直接使用 find({ _id: { $in: insertedIds } }) 进行二次确认更稳妥。
• 注意驱动版本差异：MongoDB 驱动版本不同，result.insertedCount 和 result.upsertedCount 的含义有所差异，v4+ 才统一支持 insertedIds 字段。

事务中能否使用 insertMany？——约束与风险

可以使用，但前提是：所有文档必须满足事务的约束，例如唯一索引、引用完整性，并且整个事务内的操作总大小仍然受 16MB 限制。更大的风险在于，事务中 insertMany 失败会导致整个事务回滚，无法像非事务模式那样通过 ordered: false 进行局部容错。

使用场景很有限：

• 只适合强一致性要求且数据量较小的场景。
• 不要在事务中混用 insertMany 和大量 updateOne，容易导致超时或锁表。
• 开启事务前，确认副本集配置支持事务（需要 MongoDB v4.0+，存储引擎为 WiredTiger）。

归根结底，真正影响效率的从来不是方法名，而是你是否在插入前删除了无用的 ensureIndex 调用，或者是否忘记了关闭日志级别的 slowms 设置。