我们有一个使用apache和mysql的web应用程序。 一般来说（根据Munin）我们的MySQL线程数在任何时候都在2到4之间。 有一天，我们的服务器几乎停下来。 HTTP请求很慢或根本无法通过，SSH可以工作，但是需要30秒以上的时间才能注册按键等。所以我们拉上了Munin，唯一超出正常范围的是Mysql线程数。 CPU使用率低于1％，负载低于1.0，有足够的RAM。
如前所述，线程数在2到4之间浮动。在我们慢下来的时候，它已经达到了14点。所以我开始在互联网上探索，我发现在大多数情况下，你会看到更高的线程当你开始慢速查询时计数。 如果我理解正确，请求进来需要一段时间来处理，同时其他请求进入，所以会创build一个新的线程来处理请求（是？）。 但在减速的时候，我们有0慢查询。
我的问题是：还有什么可以导致MySQL创build额外的线程。 而线程突然激增可能会导致服务器放慢速度？ 为了解决这个问题，我们重新启动了Apache，所有的事情都恢复了正常的自我。 考虑到服务器Vitals（CPU，RAM，networking等）都是理想的，线程数是唯一不合适的，这似乎是最合乎逻辑的追求作为可能的原因。
如果有关系，我们使用Mysql 5.1.40。 服务器是FreeBSD 7.2，服务器在监狱里面。
根据Apache正在做的事情，很多同时发送到Apache的请求可能会导致这种情况。 例如，一个巨大的CMS可能会在早期打开一个MySQL连接，需要很长时间才能生成一个页面，而不会closures连接直到完成。
FWIW，我发现定期轮询当前连接通常不会显示真实的图像。 你应该看看max_used_connections 。 不幸的是，这个值很难pipe理： https ： //dba.stackexchange.com/questions/6040/how-can-i-get-the-maxium-number-of-concurrent-connections-to-mysql-over-a -specif
发生这种情况时，请查看SHOW FULL PROCESSLIST;的输出SHOW FULL PROCESSLIST; 看看在睡眠状态下是否有很多进程。 至less有一个错误会导致MySQL挂在SHOW VARIABLES上 。
而不是使用：
mysql -e "show global status"|grep -i threads_connected
或者lsof
你可以考虑使用procfs本身和普通的GNU / Linux工具：
find /proc/`pidof mysqld`/fd/ -follow -type s | wc -l
我迟到了，但刚刚解决了类似的问题。 如果碰巧使用的是MyISAM存储引擎，并且存在写入操作，则所有其他读取请求必须等待，直到表级locking被释放。 如果查询跨越多个表，则会有两个复杂性：1.联合结果不会全部适合内存，并调用文件sorting，这意味着更多的磁盘I / O。 2.更多的表被locking，所以读取查询更可能排队。 在大多数情况下，MySQL将完成写入，读取将清除。 如果操作系统无法释放文件的locking（发生的频率比您想象的要多），那么MySQL线程将被卡住。