PyMongo的insert_many是否有事务性？批量插入失败的入库行为疑问

insert_many 的原生执行规则 #

PyMongo官方驱动的insert_many方法，默认启用ordered=True执行模式，核心行为固定：

• 按照传入的文档列表顺序，逐一向数据库服务端提交插入请求
• 单条请求执行成功即完成持久化，不会等整批所有请求发送完毕再统一落盘
• 一旦某条文档插入触发报错，立刻中断后续所有剩余文档的提交动作，抛出对应异常

「第1000条文档数据错误」场景下的分阶段执行结果 #

按照你设计的异常处理流程，整个执行链路分为两个独立阶段，写入结果对应明确：

第一阶段：3000条整批的首次insert_many调用 #

使用默认ordered=True参数时，执行到第1000条文档会触发插入报错，驱动立刻中断后续提交：

• 此前已执行完成的前999条文档，会正常持久化入库
• 从第1000条开始的剩余2001条文档，完全没有被提交到服务端，不会产生任何写入
• 抛出的异常会被外层Try/Except块捕获，触发预设的回退逻辑

第二阶段：异常触发后的逐条重插流程 #

进入单条插入逻辑后，程序会重新遍历整批3000条文档执行独立插入：

• 前999条已经在第一阶段完成入库的文档，如果没有配置幂等校验，会被重复写入
• 第1000条存在格式错误的文档，会触发单条插入异常，被捕获后通过pprint.pprint输出内容用于排查
• 此前未被提交的第1001-3000条正常文档，会在这个阶段顺利完成入库

核心疑问的直接对应答复 #

你提到的三种场景判断，匹配关系非常明确：

• 「全部3000条都不会写入存储」：仅在开启多文档事务、且异常触发事务整体回滚的场景下成立，常规无事务的批量插入不会出现该效果
• 「前999条会正常入库、剩余文档写入失败」：这是第一次批量调用本身的原生执行表现
• 「除1条坏数据外其余2999条都能正常完成入库」：这是回退流程跑完全程的最终目标结果，但伴随前999条文档重复入库的副作用

实操优化提示 #

• 若要跳过坏数据一次性完成整批插入、降低逐条重放的性能损耗，可直接给insert_many传入ordered=False参数：驱动会把整批所有插入请求提交给服务端，坏数据触发的错误会被统一汇总，其余正常数据全部完成插入，无需额外回退逻辑
• 若保留「逐条重放定位坏数据」的流程，建议给单条插入增加基于文档唯一标识的存在性校验，避免已写入的文档被重复插入

内容的提问来源于stack exchange，提问作者NealWalters