我说得对吗？从性能的角度来看，存储过程中的 sql 事务要比代码好得多？
目前我在存储过程中使用我的大部分事务，但有时我将代码用于更复杂的例程 - 显然我尽可能地保持在最低限度。
只是有一个复杂的例程需要太多的“变量”，用c#编写sql事务比使用SQL Server容易得多。这是代码可读性和性能之间的一条细线。
有什么想法吗？
【问题讨论】：
标签： c# sql-server transactions
代码中的事务管理（阅读 c#）是一个选项，可用于管理多个数据源或系统上的事务。对于单个数据库的事务管理，服务器端的管理总是会比较简单。但是，如果您认为代码可能需要满足在事务中添加多个数据源的情况，请将事务保留在代码级别。
【讨论】：
我相信存储过程会有更好的性能。
【讨论】：
性能各不相同； SqlTransaction 的开销可能比 TransactionScope 少，尤其是当 TransactionScope 决定需要与 DTC 纠缠时。但我不希望SqlTransaction 和BEGIN TRAN 之间有巨大 的差异，除了额外的往返行程。但是，TransactionScope 仍然很快，并且是在事务中封装多个操作的最方便的选项，因为环境事务不需要每次都手动与命令关联。
isolation-level 可能是一个更好（也更重要）的因素。 TransactionScope 默认为最高（可序列化）。较低的隔离级别允许更多的阻塞（但存在不可重复读取等风险）。 IIRC TSQL 事务默认为较低级别之一。但是可以针对所有 3 个选项调整隔离级别。
【讨论】：
如果您的意思是您用 C# 编写 SQL 事务并使用 ADO.Net 或类似方法来执行它们，那么它们可能效率较低，因为 SQL 将缓存存储过程的查询计划（现在实体框架也是如此 -虽然仍然没有我认为的 proc 快）所以实际上你可能应该反过来做 - SQL 中的复杂过程以获得缓存的好处（如果它是那么简单......）
【讨论】：
这取决于什么应用程序。
但我会说，在大多数情况下，最好让数据库中有逻辑感到惊讶。在数据库中拥有业务逻辑的一个非常有利的地方是，即使您拥有 WinForms 版本和 Web 或其他任何内容，它也将是相同的
但是，如果您谈论的是 SQL 中的 CLR。不利的是，DBA 发现任何错误或相关问题变得更加困难。性能。
【讨论】：
我支持TransactionScope。按照 Marc 的说法，在您的 TransactionScope 上使用工厂方法将隔离级别降低到 READ COMMITTED，这是我能想到的最常见的用法。
请注意，您可以同时使用 SQL 事务和 TransactionScope - SQL BEGIN TRAN / COMMIT TRAN 对 TransactionScope 几乎没有影响（除了增加/减少 @@TRANCOUNT） - 如果您确实需要，可以这样在别处调用相同的 SQL Sproc，例如从即席查询中，您仍将受益于事务。
TransactionScopeIMO 的好处是，如果您确实需要进行 2 阶段提交（例如，多个数据库、队列或其他 XA 事务），它将为您管理 DTC。对于 SQL 2005 及更高版本，它与 Lightweight Transaction Manager 一起使用，因此不需要 DTC，例如如果所有访问都针对一个数据库，则一次连接一个。
【讨论】：