MongoDB 5.0文档流式插入处理方法

流式写入 MongoDB？先搞清楚这几个关键坑点

MongoDB 5.0 并未提供原生的“流式插入”接口——不存在像 insertStream 这样的命令。所谓的“流式插入”，本质上是在应用层通过 insertMany 和 BulkWrite 进行封装实现。简单来说，就是需要自己动手构建这个“管道”。既然要自行搭建，就必须掌握几个核心要点。

insertMany 模拟流式写入，批次大小决定成败

直接将几万条文档塞入一次 insertMany 调用会怎样？大概率触发 BSON 大小限制（16MB），甚至导致内存溢出。因此必须按固定批次切分，例如每 100 到 500 条一批。

• insertMany 单次最多支持约 1000 条文档，超过会报 errmsg: "BSON object too large"——实际取决于单条文档体积，但 1000 条是经验红线。
• 批次太小呢？比如设为 10，网络往返次数激增，吞吐量直接腰斩；批次太大呢？比如 2000，可能让连接阻塞或触发超时。
• 实战建议先从 100 条开始，然后根据实测响应时间和错误率动态调整。这个调试过程没有捷径可走。

ordered: false 是流式场景的生存法则

流式数据中混入“脏数据”几乎是常态，例如重复的 _id、类型冲突等。如果使用默认的 ordered: true，一条失败会导致整批中断，后续数据全部积压——这完全违背了“流”的连续性原则。

所以必须显式传递参数：

db.collection.insertMany(docs, { ordered: false })

• 使用 ordered: false 时，失败项会被跳过，其余文档继续执行。返回结果中的 writeErrors 字段会列出具体哪些文档出错。
• 注意：即便设置为 unordered，单条文档的校验约束依然生效（例如 _id 冲突仍会报错），但不会影响其他文档。
• 还有一个绝对不能踩的坑：不要在事务中使用 ordered: false——MongoDB 5.0 不允许，会直接报错。

别再使用 db.collection.insert()

在 mongosh 1.8+（MongoDB 5.0 默认配套）中，db.collection.insert() 已被标记为 deprecated，且行为存在诸多问题：

• 传入数组时，它实际调用的是旧版批量逻辑，错误处理粒度很粗，只返回成功或失败，无法区分具体哪条失败。
• 无法设置 ordered 参数，也无法兼容现代驱动中的 writeConcern 行为。
• 改用 insertMany 后，错误对象结构统一，日志解析和重试逻辑都方便很多。升级成本极低，收益却很实在。

“流式”的边界在应用层，不在数据库服务端

MongoDB 5.0 的复制集 oplog 和 changeStream 属于“流式消费”，而非“流式插入”。插入动作始终是离散的 RPC 请求。数据库不会自动替你处理流量压力。

要实现持续低延迟写入，关键不在于数据库命令，而在于客户端的设计：

• 是否启用了连接池？Driver 默认 poolSize 只有 5，高并发下需要调大。
• 是否复用了 bulkWrite 实例？避免反复创建 write model 对象，能节省大量开销。
• 是否有背压控制？例如 Node.js 的 stream.pipeline 或 Java 的 Flow.Subscriber 来控制上游数据吐速。

漏掉任何一环，“流式插入”就可能变成内存泄漏或连接打满。坦白说，这几个坑踩过的人不少。希望这篇文章能帮你少走一些弯路。