单条insertOne比批量insertMany慢，因每次调用都触发完整网络往返、协议解析、内存分配与同步写确认；insertMany将多文档打包为单请求，显著降低开销。
单条插入比批量插入慢，不是“函数写法问题”，而是网络往返、写确认开销和驱动层调度被重复放大了。
insertOne 为什么每次都要走完整链路
每调用一次 insertOne，驱动就发一个独立的 OP_INSERT wire protocol 包，MongoDB 服务端要为它单独做：解析 BSON → 校验结构 → 分配内存 → 写入内存（或 journal）→ 返回响应 → 清理上下文。这个过程哪怕只花 2ms，在 1 万次调用里就是 20 秒。
- 即使连接复用，也无法合并请求；每个
insertOne都是独立 round-trip - 默认
writeConcern: { w: 1 }虽快，但仍是同步等待主节点返回，无法并行化 - 如果误设了
w: "majority"或j: true，单次延迟直接跳到 50–200ms，1000 次就卡死 - 驱动还要为每次调用分配临时对象（如
InsertOneOptions实例），GC 压力明显上升
insertMany 怎么省掉这些开销
insertMany 把 N 条文档打包进一个 wire protocol 请求，服务端一次解析、一次内存分配、一次 journal 刷写（若启用）、一次响应返回 —— 网络和 CPU 开销基本不随文档数线性增长，而是接近常数级。
- 实测：本地插入 10 万条，
insertOne耗时 ~8.2s，insertMany（分批 1000 条/批）仅 ~1.1s - 关键不在“批量”本身，而在避免重复协议解析和 socket 往返；远程库延迟越高，差距越明显
- 注意：不是批得越大越好；单次超过 1000 条易触发 socket 缓冲区溢出或 OOM，尤其文档含大字段时
别让 writeConcern 悄悄拖垮 insertOne
很多团队发现单条插入突然变慢，查了一圈磁盘、CPU、索引，最后发现是全局 writeConcern 被框架或中间件改成了 { w: "majority", j: true } —— 这会让每个 insertOne 等待多数节点 journal 刷盘，延迟从 2ms 暴涨到 100ms+。
- 检查方式：Node.js 驱动读
client.options.writeConcern；Java 查MongoClientOptions.getWriteConcern() - Spring Data MongoDB 中，
@WriteConcern注解或mongoTemplate.setWriteConcern()会覆盖所有单条操作 - 副本集里
w: "majority"不是“安全升级”，而是明确选择几十毫秒延迟；standalone 模式下它等价于w: 1，无额外代价
真正该换批量的临界点在哪
只要单次插入文档数 ≥ 2，就该考虑 insertMany；但实际切换时机取决于你的错误容忍和运维能力。
- 业务允许部分失败？用
{ ordered: false }+writeConcern: { w: 1, j: false } - 文档 ID 由客户端生成（如 UUID）？可放心分批，无需担心
_id冲突 - 依赖
insertedIds做后续关联？注意insertMany返回的是数组，不是单个 ID，别在循环里反复取result.insertedIds[0] - 别为了“看起来快”而关 journal（
j: false）还部署在 HDD 上；SSD 可接受，HDD 建议至少保留j: true或用w: 1+ 定期备份
最常被忽略的一点：批量插入后禁用索引再重建，比单纯换 insertMany 还能再提 30%+ 速度 —— 但这个操作必须在业务低峰期做，且不能影响正在查询的集合。
