事务内读操作拖慢MongoDB性能，因其强制快照读导致锁范围扩大、快照开销上升、WiredTiger缓存压力增大；仅两类读必须留在事务内：依赖一致性的读和用于写冲突判断的读。
为什么事务里做读操作会拖慢 MongoDB 性能
MongoDB 事务本质是加锁 + 日志 + 一致性快照，只要读操作在 session.startTransaction() 和 session.commitTransaction() 之间，就会强制走事务快照读（snapshot read），哪怕你只是 collection.findOne() 查一条不相关的文档。这会导致：锁范围扩大、快照维护开销上升、WiredTiger cache 压力变大——尤其在高并发写场景下，读操作反而成了事务瓶颈。
哪些读操作必须留在事务内
只有两类读操作不能移出去：依赖事务一致性的读（比如“先查余额，再扣款”）和 用于写冲突判断的读（如基于旧值做条件更新）。其他所有读都该挪走。常见误留场景包括：
-
collection.countDocuments()统计用于日志或监控（与业务逻辑无关） -
collection.find().toArray()加载配置或字典数据（这些数据本身不参与事务逻辑） - 为日志拼接用户昵称而查
users.findOne()（昵称不参与扣款/状态变更）
怎么安全地把读移到事务外
核心原则是：**读操作必须在事务开始前完成，且结果传入事务函数作为不可变输入**。注意三点：
- 不要在事务内调用异步读（如
await collection.findOne()），哪怕它看起来“只是读” - 如果读结果用于写条件（例如
updateOne({ _id, status: "pending" })），确保该读发生在事务快照中——此时必须保留在事务内，不能简单“提前读” - 对多集合关联读，若只有一部分参与事务逻辑，拆成“事务外预读 + 事务内局部验证”
示例（Node.js）：
// ✅ 正确：配置类读提前完成
const config = await configs.findOne({ key: "fee_rate" });
const user = await users.findOne({ _id: userId }); // 用户基础信息，不参与状态变更
<p>// 事务只做原子写
await session.withTransaction(async () => {
const order = await orders.findOne({ _id: orderId }, { session });
if (order.status !== "created") throw new Error("invalid status");</p><p>await orders.updateOne(
{ _id: orderId },
{ $set: { status: "paid", fee: config.rate * order.amount } },
{ session }
);
});</p>容易被忽略的隐式读操作
有些读不是显式 find，但一样进事务快照：
-
collection.bulkWrite()中的upsert: true会隐式执行一次查询判断是否存在 -
collection.replaceOne()默认带upsert: false，但如果设为true，就等价于“读+写” - 使用
$expr的更新条件（如{ $gt: ["$updatedAt", "$createdAt"] }）需要读取文档字段，也走快照
这类操作一旦出现在事务里，又没实际业务必要，就是性能黑洞。检查 mongod 日志里的 transaction 段落，留意 numReads 字段是否异常高。
事务不是万能隔离罩，它只解决“写-写冲突”和有限的“读-写一致性”，别把它当读操作的保险柜。
