即使您是本地事务，根据本文，如果您在同一事务范围内打开多个连接，事务仍将升级为MSDTC：http : //msdn.microsoft.com/zh-
cn/library/ms229978(v= vs.110）.aspx
在以下情况下发生升级，导致System.Transactions基础结构将事务的所有权转移到MSDTC：
*事务中至少有两个支持单阶段通知的持久资源。例如，加入的单个连接不会导致事务升级。但是，每当您打开与数据库的第二个连接而导致该数据库加入时，System.Transactions基础结构都会检测到它是事务中的第二个持久资源，并将其升级为MSDTC事务。
注意：我已经阅读了一些文章，指出这仅适用于SQL 2005，并且SQL 2008+对于MSDTC升级更为精明。这些说明SQL 2008仅 在同时
打开多个连接时才会升级为MSDTC
。
另外，您的内部异常是
Timeout（System.Data.SqlClient.SqlException：超时已过期），而不是
Deadlock。虽然两者都与阻止有关，但它们不是同一件事。
timeout当阻止导致应用程序停止等待被另一个连接阻止的资源时发生A
，以便当前语句可以获取对该资源的锁定。一
deadlock，当两个不同的连接都用相同的资源竞争他们的方式阻止他们将永远无法完成，除非其中一个连接被终止时，以及（这是为什么僵局错误信息说：“交易......已经选择作为僵局的受害者”）。由于您的错误是超时，因此这说明了死锁查询返回0计数的原因。
System.Transactions.TransactionInDoubtException来自MSDN（http://msdn.microsoft.com/zh-
cn/library/system.transactions.transactionindoubtexception (
v=vs.110 )
.aspx）指出：
当尝试对有疑问的事务执行操作时，将引发此异常。当无法确定交易状态时，便会怀疑交易。特别是，对于该事务，永远不会知道事务的最终结果（无论是提交还是中止）。
当尝试提交事务并将事务变为InDoubt时，也会引发此异常。
原因：在期间发生了一些事情
TransactionScope，导致交易结束时状态未知。
原因：可能有许多不同的原因，但是在不发布源代码的情况下很难确定您的具体原因。
检查事项：
- 如果您使用的是SQL 2005，并且打开了多个连接，则您的事务将被提升为MSDTC事务。
- 如果您使用的是SQL 2008+，并且同时打开了多个连接（即，嵌套连接或并行运行的多个ASYNC连接），则该事务将被提升为MSDTC事务。
- 如果您的代码中正在运行“ try / catch {retry if timeout / deadlock}”逻辑，则当事务在内时，这可能会引起问题
System.Transactions.TransactionScope
，因为SQL Server在超时或超时时会自动回滚事务的方式发生死锁。
