在 ado.net 代码中实现事务控制是否会对性能产生影响？答案

【问题标题】：Is there any performance impact of having transaction control implemented in ado.net code?在 ado.net 代码中实现事务控制是否会对性能产生影响？
【发布时间】：2013-05-13 12:06:57
【问题描述】：

我应该调整一个 .net 应用程序，开发人员已经在 ado.net 中实现了事务控制，即使是使用单个 sql 命令的连接也是如此。就个人而言，我在这种情况下避免使用 ado.net 事务控制，并在 db 端实现它。我相信除了 for sql 命令之外，每个 ado.net 事务控制命令都会调用 db，这会导致性能下降。我在后端理解，两者都是等价的。我想知道这是否是一个问题，如果是，那么它有多重要。

【问题讨论】：

通常你会从 ADO.NET 调用一个存储过程，并在存储过程中实现一个 BEGIN TRAN、COMMIT TRAN。
@cvraman “一般”通常是过度概括
@Marc : 是的...但是由于发布此问题的人有一个要连接的数据库并且对性能感到焦虑，所以我在这种情况下发表了评论。
@cvraman 我不同意 ;p 我在这里看到了各种各样的方法，足以说明像“通常你会......”这样的笼统陈述是有问题的。
@MarcGravell：我一直在 T-SQL 代码中实现它，所以我可能有点偏颇。不过想知道替代方法。

标签： c# sql-server-2008 c#-4.0 ado.net

【解决方案1】：

这是否是一个问题取决于您需要多快。这里涉及的时间基本上是额外的 2 x {latency}（一个用于“begin”，一个用于“commit”/“rollback”），其中 {latency} 取决于您的网络，但通常约 0.25 毫秒；所以 - 称它为每次操作 0.5 毫秒。在大多数情况下，这 0.5ms 本身是无关紧要的，尤其是与实际的“做”代码相比。如果你去 DB 的次数足够多，这是一个重要的数字，那么我要改变的第一件事就是：减少去 DB 的次数。

在大多数情况下，我不会过分担心这是否在 TSQL 和连接上实现：两者都可以，而且更容易确保基于连接的方法可证明是正确的。我在 TSQL 回滚代码中看到了很多错误...

要确定，您必须进行概要分析，但同样：请记住，时间通常是 a：孤立的（即每页不是 200 个，等等），和/或 b：被实际情况淹没“做”代码

【讨论】：

当我刚刚看到代码时，我实际上并不关心这个。从 VS Profiler 检测报告中，我可以看到这些方法中的每一个都需要 40-50 毫秒，这当然包括数据库服务器上的实际命令执行（我也记录了从不超过单个数字的命令）。我猜可能是网络问题，但目前还没有其他服务器可以测试。想知道这是不是一般问题
@meraj 好吧，分析可能是你最好的选择。像 mini-profiler 这样的东西可能会有所帮助。注意：一旦您在事务中运行，代码必须以不同的方式运行才能满足保证 - 并且几乎总是会慢一点。这不取决于您创建事务的如何（除非需要说明的是，不同的事务技术具有不同的默认“隔离级别”——这本身就是明确指定隔离级别的一个很好的理由而不是使用默认值）。任何感知到的减速都可能是由于隔离级别造成的。