ASP.NET WebService查询MSSQL超时（连接池大小）问题求助

这个错误System.InvalidOperationException: Timeout abgelaufen...是典型的数据库连接池耗尽问题——你的应用没有正确释放数据库连接，导致连接池里的所有连接都被占用，新请求拿不到连接就触发超时了。保存.asmx后能恢复正常，是因为重启了应用域，连接池被清空，所以暂时能正常处理请求，直到连接再次被占满。

给你几个针对性的解决思路：

• 用Using语句确保连接自动释放（最关键）
  手动调用con.Close()不可靠，因为如果代码执行过程中抛出异常，Close()可能根本不会被执行。VB里的Using语句会自动处理连接的释放，不管有没有异常，都会把连接放回连接池。比如你的GetSchueler方法应该改成这样：

  Public Function GetSchueler(ByVal un As String) As Schueler
      Using con As New SqlConnection(YourConnectionString)
          con.Open()
          ' 执行SQL查询、读取数据的逻辑
          ' ...
      End Using ' 这里会自动关闭并释放连接到池
  End Function
  

  这是解决连接泄漏的核心手段，一定要替换掉手动Close的写法。

• 检查是否存在连接泄漏的其他场景
  比如有没有在某些条件分支里（比如If...Else）忘记关闭连接？或者使用了全局的SqlConnection对象？全局连接会被多个请求争抢，很容易导致连接无法正确释放。记住：每个数据库操作都应该创建独立的连接，用Using包裹，不要复用全局连接。

• 排查连接池配置（次要，先解决泄漏再调）
  如果你的应用并发确实很高，连接池默认的最大容量（100）可能不够。可以在连接字符串里调整Max Pool Size参数，比如：

  Server=yourServer;Database=yourDB;User Id=xxx;Password=xxx;Max Pool Size=200;
  

  但注意：这只是缓解手段，如果连接泄漏的问题没解决，调大池容量只是推迟报错时间，最终还是会耗尽。

• 验证连接是否真的被释放
  可以用SQL Server的sys.dm_exec_connections视图查看当前的连接数，对比应用的并发请求数，看看是否有连接没有被及时释放。比如执行这个查询：

  SELECT COUNT(*) FROM sys.dm_exec_connections WHERE program_name = '你的应用名称'
  

  如果请求结束后连接数没有下降，说明确实存在泄漏。

先把Using语句的改造放在第一位，这应该能解决大部分问题。如果改完还是有问题，再排查其他场景。

内容的提问来源于stack exchange，提问作者Felix Niedermann