C# MySQL.NET Connector 5.2.3-Win 2k3-随机错误-无法连接到任何主机-重新启动网站并修复

我在运行MySQL连接器5.2.3的Win 2k3盒上遇到了一个奇怪的错误。在过去24小时内发生了3次，但在过去6个月内总共只发生了4次

[异常：引发了类型为“System.Exception”的异常。]MySql.Data.MySqlClient.NativeDriver.Open+259

[MySqlException 0x80004005:无法连接到任何指定的MySQL主机。]

如果我在IIS中重新启动应用程序池和网站，问题会暂时得到解决，但如上所述，在过去24小时内已经发生了3次。在此期间也没有服务器更改

---

有什么想法吗？

这是一个基于有限信息的猜测

我认为您没有正确地处理数据库连接。确保已将连接包装在using子句中。打电话，靠得太近还不够。这会关闭连接，但不会处理它

第二，为什么是现在而不是几个月前，可能与您现在看到的通信量与之前的通信量以及您现在实例化的数据库连接量与之前的通信量有关

我刚刚接到电话，想帮助我开发一款表现出完全相同行为的应用程序。一切都很好，直到有一天它开始崩溃。很多他们在using子句中包装了sql命令对象，但没有连接。随着通信量的增加，连接池被填满并爆裂。一旦我们使用强制调用dispose的子句来包装连接，一切都很顺利

更新 我只想澄清一件事。SqlConnection是非托管资源的包装器；这就是它实现IDisposable的原因。当您的连接对象超出范围时，可以对其进行垃圾收集。从编码的角度来看，你真的不知道什么时候会发生这种情况。可能需要几秒钟，也可能更长

但是，SqlConnection与之对话的连接池是一个完全独立的实体。它不知道该连接将不再使用。Dispose方法基本上告诉连接池这段特定的代码是通过连接完成的。这意味着连接池可以立即重新分配这些资源。请注意，一些MS文档指出Close等同于Dispose，但我的测试表明这根本不是真的

如果您的站点创建的连接多于显式处理的连接，那么连接池可能会根据垃圾收集发生的时间而填满。这实际上取决于创建的连接数和接收的通信量。更高的流量=更多的连接和GC运行之间更长的时间

现在，默认的IIS配置为每个工作进程提供100个执行线程。应用程序池的默认配置是100个连接。如果在使用连接后立即处理连接，则永远不会超过池大小。即使您进行了很多db调用，请求线程也会一次调用一个

但是，如果您添加了更多工作进程，增加了每个进程的线程数，或者没有处理好连接，那么您就有可能超过连接池的大小。请注意，您可以在中控制池大小

---

不要担心调用dispose然后在处理单个页面时多次重新打开连接的性能。池的存在是为了保持与服务器的连接处于活动状态，以便使这成为一个非常快速的过程。

如何管理连接-方法与类级别范围？您是否正确地进行了处置，以便返回到池的连接？方法级别作用域。我们接近了，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于，终于。这不管用吗？回首过去，我看到好几个地方没有垃圾处理，只有一个关闭的地方。那么这可能会导致问题？我必须对2之间的差异进行更多的研究。这些连接也是上面提到的方法级范围。@Zach。using子句实际上被解释为try..finally，当编译下来时。不过，最好使用using包装实现IDisposable的任何内容，因为它更紧凑、更清晰。@Zach:close只关闭连接，不释放资源。最终GC将清理连接，但随着通信量的增加，这需要更长的时间。dispose调用告诉连接池可以立即重新分配这些资源；这就是你需要的。