C# SqlConnection.BeginDbTransaction调用超时问题排查与解决

核心疑问直接答复 #

• 能不能单独给事务开启操作配更长超时？
  你之前通过连接字符串Timeout参数解决的是连接建立阶段的超时，这个参数不控制连接建好之后的操作等待时间。在你当前使用的System.Data.SqlClient 4.7.0版本里，BeginTransaction操作没有单独的超时配置项，内部默认直接复用连接的ConnectionTimeout值作为等待阈值，就算把连接超时改长，也只是间接拉长事务等待时间，属于掩盖问题的做法，不推荐作为首选修复方案。
• 故障会不会是网络问题导致？
  有可能，但概率不高，网络问题只会占这类故障的20%不到，大部分这类事务开启超时都是数据库端阻塞或者应用侧连接泄漏导致的。
• 升级.NET 6能不能解决？
  你的判断是对的，.NET Core 3和.NET 6内置的System.Data.SqlClient实现基本一致，本身没有针对这个场景的修复，盲目升运行时没用。

按优先级排查修复 #

• 优先排查SQL端事务阻塞（80%以上同类故障根因）
  开启事务需要在SQL Server实例端申请事务管理器的相关锁，如果实例上存在长时间未提交的孤儿事务、跑了很久没结束的大查询/DDL语句，会直接阻塞新事务的开启请求，等待超时就会抛出你看到的Win32错误258。
  报错发生时直接在SQL Server实例上执行下面的诊断语句，就能直接定位阻塞源：

  -- 查询当前阻塞链
  SELECT 
      blocking_session_id 阻塞会话ID,
      session_id 被阻塞会话ID,
      wait_type 等待类型,
      wait_time/1000 已等待秒数,
      t.text 对应执行SQL
  FROM sys.dm_exec_requests r
  CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) t
  WHERE blocking_session_id <> 0
  

  查到阻塞会话后，先确认会话来源，如果是已经异常断开、没有对应业务请求的孤儿会话，直接KILL对应会话ID就能临时恢复，后续再排查对应业务为什么没有正确提交/回滚事务。
• 排查应用侧连接泄漏问题
  你之前已经遇到过连接阶段的超时，重点检查代码里所有SqlConnection、SqlTransaction有没有用using块正确释放——如果事务开启后代码抛异常，没有走回滚、Dispose逻辑，会导致连接被长期占用无法回到连接池，后续新请求拿到的可能是已经半失效的僵尸连接，调用BeginTransaction时就会卡到超时。
  临时验证直接在连接字符串里加上Pooling=false关掉连接池测试，如果问题消失就能确定是连接泄漏，逐行检查数据库操作代码的资源释放逻辑即可。
• 最后排查网络层配置问题
  如果应用和SQL Server之间隔了防火墙、云厂商SNAT网关、四层负载均衡，检查这些设备的TCP空闲连接回收阈值：很多云环境默认会把空闲超过4分钟的TCP连接直接掐断，而老版本SqlClient的连接池默认会把空闲连接保留10分钟，一旦请求拿到被网关掐断的僵尸连接，发事务请求就会等不到响应超时。
  这种场景不需要改超时，直接在连接字符串里加Connection Lifetime=180，让连接池里的连接最长存活3分钟（短于网关的空闲回收阈值），就能自动规避这个问题。

可选的客户端升级方案 #

如果前面的排查都没解决问题，不需要升级到.NET 6，直接在你现有的.NET Core 3项目里，把System.Data.SqlClient 4.7.0卸载，换装微软官方后续维护的Microsoft.Data.SqlClient最新稳定版即可。System.Data.SqlClient早在2019年就停止功能更新和bug修复了，所有事务、连接池相关的问题修复都只在Microsoft.Data.SqlClient里迭代，这个包完全兼容你现有System.Data.SqlClient的写法，几乎不需要改业务代码。

不要一上来就盲目拉长超时时间，超时是故障的信号不是故障本身，盲目加超时只会让阻塞、连接泄漏的问题越积越重，最后拖垮整个数据库实例。

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