SqlDeadlockHelper很长一段时间以来，我们一直在使用一种机制（一个名为 的类），它在尝试由于死锁而失败的数据库调用时帮助了我们很多。SqlDeadlockHelper将捕获 a SqlException，认识到这是一个死锁，然后再试一次。第二次尝试几乎总是成功。
对命令和/或连接超时执行此类操作是否安全？我的意思是，在 SQL Server 上完成工作是不可能的，只能在数据返回给调用者之前超时，是吗？
编辑：
事务已被提及作为将调用视为工作单元的一种方式。这样它就可以成功或完全回滚。但是，一个只做一件事的 ADO.NET 调用又如何呢？是否有必要将其包装在事务中？
根据您的工作单元，SQL 有可能在死锁并引发错误之前完成部分工作。您处理工作单元的方式是使用事务。大多数 SQL 数据库都支持事务。您需要将工作单元包装在 Begin、Commit 和 Rollback 事务中。
http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqltransaction.aspx
检测到死锁后，数据库引擎通过选择其中一个线程作为死锁牺牲品来结束死锁。数据库引擎终止正在为线程执行的当前批处理，回滚死锁牺牲品的事务，并向应用程序返回 1205 错误。为死锁牺牲品回滚事务会释放事务持有的所有锁。这允许其他线程的事务变得畅通并继续。1205 死锁牺牲品错误在错误日志中记录有关死锁所涉及的线程和资源的信息。
因此，您的事务已安全回滚，您可以再试一次。
编辑
作为一个懒惰的a**e，我没有彻底阅读你的问题。让我们来看看：
对命令和/或连接超时执行此类操作是否安全？
我不会做同样的概括，因为您最终可能会尝试从根本无法访问的数据库中读取数据。您应该有最大的重试次数。
我的意思是，在 SQL Server 上完成工作是不可能的，只能在数据返回给调用者之前超时，是吗？
从来没有听说过，如果你使用transactions应该是不可能的。并且您应该使用它们以及 XACT_ABORT 标志，Specifies whether SQL Server automatically rolls back the current transaction when a Transact-SQL statement raises a run-time error.但是，工作可能无法完成或未完成 - 请参阅僵尸事务。