利用bulkWrite与Session在MongoDB事务中执行批量upsert操作的步骤详解

# MongoDB事务中bulkWrite的硬核规范：session是命，writeConcern是禁区 在MongoDB事务中执行批量upsert操作时，存在几个不可绕过的硬性约束。首先需要明确：`bulkWrite()` 必须配合显式 `session` 使用，而且绝对不能手动设置 `writeConcern`——否则你会遇到那个经典报错：`Cannot specify write concern in transaction`。

## 事务内调用 bulkWrite 的三大硬性要求 如果你以为只需要在事务外层包裹一个 `with_transaction()` 就能轻松搞定，那多半会踩坑。事实上，事务中的 `bulkWrite()` 必须对齐以下三个约束： - **session 必须显式传入**：调用 `bulkWrite()` 时必须带上 `session` 参数，且该 `session` 必须源自同一个 `MongoClient`，并已通过 `start_session()` 方法创建 - **writeConcern 是禁区**：不能在 `bulkWrite()` 的 options 中传递任何 `writeConcern`（即使设置为 `{w: 1}` 也不行），否则会直接抛出 `OperationFailure` 异常 - **upsert 行为完全受事务控制**：所有操作中的 `upsert: true` 是否成功，完全绑定事务生命周期——事务失败则全部回滚，成功则全部提交 关键点在于第三点：upsert 并非“单独生效”，它的可见性完全依赖于事务提交的时机。 ## PyMongo 实战：带 upsert 的有序批量写入 下面是一段在 PyMongo 中安全执行的最小可行代码。请注意 `session` 的生命周期管理，以及参数的剥离——切勿将 `writeConcern` 混入其中： ```python with client.start_session() as session: def callback(session): result = collection.bulkWrite([ {"updateOne": { "filter": {"_id": "user_1001"}, "update": {"$set": {"status": "active", "last_login": datetime.utcnow()}}, "upsert": True }}, {"updateOne": { "filter": {"email": "test@example.com"}, "update": {"$inc": {"login_count": 1}}, "upsert": True }} ], session=session) # ← 只传 session，不传 writeConcern print(f"Upserted: {result.upserted_count}, Modified: {result.modified_count}") session.with_transaction(callback) ``` 这里有一个容易忽略的细节：`session` 是唯一必须的额外参数。`ordered=True` 是默认行为，它能确保操作按顺序执行——如果你依赖前序 upsert 的结果（例如先插入用户、再更新其配置），这一默认设置正好能找到兜底。 ## ordered=False 在事务中的隐性代价 虽然 `ordered=False` 允许单个失败的操作不会中断整体流程，但在事务中它隐藏着几个隐性陷阱： - **事务的原子性被“表面化”**：即使部分 upsert 失败，只要没有抛出异常，事务仍可能视为成功提交。你只能依靠 `result.upserted_ids` 和 `result.upserted_count` 去反向排查哪些操作实际生效 - **逻辑顺序无法保证**：如果你期望先执行 `insertOne` 主文档，再执行 `updateOne` 关联子文档，`ordered=False` 可能导致后者因主文档尚未就绪而静默失败——错误可能不会暴露，但数据已经出现偏差 - **错误信息藏得很深**：它不会出现在顶层异常中，而是隐藏在 `result.bulk_write_result` 的 `writeErrors` 字段里，很容易被开发者遗漏 ## upsert 在事务中真正生效的边界 事务里的 upsert 并非“单独生效”，它的所有行为都受事务生命周期约束： - **事务未提交前，其他会话无法查询到任何 upsert 产生的数据**——即使查询相同的 `_id` 也无法看到 - 如果某个 `updateOne` 携带 `upsert: true` 执行时，匹配到已有文档就走 update 分支；未匹配到则走 insert 分支。这两条路径在事务内部都受 ACID 保护 - **不要在事务内混用 `bulkWrite()` 和单条 `insert_one()`**，特别是当它们操作同一字段（例如 `_id`）时，极易触发重复键冲突，并且错误定位相当困难 还有一个容易被忽略的点：事务中 `bulkWrite()` 的性能并不比单条操作提升多少。因为网络往返次数并没有减少——事务本身需要发送 `commitTransaction` 或 `abortTransaction`。其核心价值在于数据一致性，而非吞吐量。