我的基本问题是这对服务器有什么样的影响？
比方说，我公司有一个比较老的程序，它以高速率打开与MySQL数据库服务器的连接（他们在应用程序中所做的一切基本上都会打开服务器连接）。 然而，这个应用程序的devise并不是在创build后处理连接的方式。 很多时候，连接仍然是开放的，但不会再次使用，我想你可以说是开放的“死亡”连接。
他们只是保持连接，直到服务器超时，或直到pipe理员进入并手动删除睡眠连接。 我猜这可能是有时不能连接错误等，我们从其他系统尝试访问MySQL数据库负责？ （达到连接限制）
这是否会减慢服务器呢？ 好奇这究竟是什么原因造成的。
你可以用MySQL中的超时值来玩一些游戏。
例如，“ wait_timeout ”和“ interactive_timeout ”的默认值是28800（即8小时）
你可以通过运行这个来看看它们的设置：
SHOW VARIABLES LIKE 'interactive_timeout';<BR> SHOW VARIABLES LIKE 'wait_timeout';
如果你想把它们降低到1分钟，那么就不需要重新启动MySQL。
以root用户身份运行它们：
SET GLOBAL interactive_timeout=60;<BR> SET GLOBAL wait_timeout=60;
这将确保任何新的MySQL连接将在60秒内超时。
然后将这些行添加到[mysqld]部分下的/etc/my.cnf
interactive_timeout=60 wait_timeout=60
当然，重新启动mysql以删除剩余的睡眠连接更容易。 从那里开始的所有连接将在60秒内超时。
试试看，让我们知道！
除非你在真正有限的服务器上运行，否则这可能会减慢速度。 这样做的应用程序将缓慢mem泄漏，直到达到最大连接，但我怀疑这将是那么多的内存。
你可能遇到的主要问题是你已经注意到的问题，最大限度地提高连接。 你最好的select是修复程序来清理它自己。 如果由于某种原因，这不是一个选项，你可能会在运行该应用程序的框中放置一个连接限制，以便该框不能打开超过X连接到mysql服务器，所以它不能垄断它（我不知道你用什么操作系统来知道这是否可能，但是如果是linux的话，这将是一个简单的iptables规则）。
yes，interactive_timeout和wait_timeout。 只要mysql中的清理线程继续运行，它将自行清除它们
直到用完连接并且合法客户端无法连接，它才会导致问题。
当然，你需要设置max_connections足够低，以免内存或地址空间不足（MySQL每个连接使用一个线程）。 你不应该在一个32位的系统上运行mysql，但是如果你这样做，这意味着你需要（实际上）有max_connections <1000。
如果应用程序服务器无法closures连接，则可能是资源泄漏。 让服务器把它们解决掉会解决mysql的问题，但可能不会释放内存（等）在另一端。 错误的应用程序服务器将最终失败，如果不加以控制。 它确实需要修复。
另外，在设置超时时间时要非常小心，有些应用程序希望连接不会超时。 默认是8小时，所以把它改为1分钟似乎非常激烈。