.NET C#：只读数据库调用用TransactionScope致内存泄漏，移除是否可行？

你的直觉完全在线——对于只读数据库查询来说，这里的TransactionScope确实属于多余的代码，而且它大概率就是导致堆内存中堆积数百万InternalTransaction对象的罪魁祸首。下面我们一步步拆解：

为什么TransactionScope会引发内存泄漏？ #

当你创建TransactionScope实例时，.NET会在后台生成一个InternalTransaction对象来管理事务上下文。哪怕你设置了Timeout = TimeSpan.Zero，这个对象的回收也可能因为事务上下文的隐式传播机制而被延迟。如果这个查询方法被高频调用，这些未及时被GC回收的InternalTransaction就会不断堆积，最终引发严重的内存泄漏问题。

移除TransactionScope的合理性 #

从你的描述来看：

1. 这是只读查询，不需要事务的原子性、一致性保障；
2. 系统中的写操作完全没有使用TransactionScope，说明整个系统不存在分布式事务或者跨资源的事务协调需求；
3. 你设置的IsolationLevel.ReadCommitted本身就是大多数数据库的默认隔离级别——即使不手动声明事务，数据库也会自动保证这个级别的数据一致性（除非你的数据库全局配置被修改过）。

所以移除这段using代码块，完全不会影响查询的正确性，反而能彻底解决内存泄漏问题。

需要确认的几个遗漏要点 #

虽然移除操作风险很低，但还是有几个细节需要验证：

• 检查数据库驱动的默认行为：部分旧版本的数据库驱动（比如早期的SqlClient）会默认把单个查询包装在隐式事务中，但这和TransactionScope的显式事务是两回事，不会导致同样的内存堆积问题，不用过于担心。
• 确认无隐藏的事务依赖：有没有可能这段代码未来会被修改，加入写操作？不过从方法名GetFullEventHistory来看，它的职责非常明确是只读查询，这种可能性极低。
• 验证隔离级别是否符合预期：移除后，可以通过数据库日志或者查询工具，确认查询依然在ReadCommitted隔离级别下执行（避免读到未提交的脏数据）。

修改后的代码示例 #

去掉多余的TransactionScope后，代码会更简洁，同时彻底消除内存泄漏的根源：

public IEnumerable<IEvent> GetFullEventHistory() 
{
    var events = _store.GetFullEventHistory();
    IList<IEvent> deserialisedEvents = GetEvents(events);
    return deserialisedEvents;
}

总的来说，你的判断是正确的，移除这段不必要的TransactionScope是解决当前内存泄漏问题的最优方案。只要确认上述几个小细节，就可以放心修改。

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