我们有一个使用 apache 和 mysql 的 Web 应用程序。通常（根据 Munin）我们的 MySQL 线程数始终在 2 到 4 之间。前几天，我们的服务器几乎停止了。HTTP 请求很慢或者根本无法通过，SSH 可以工作，但需要 30 多秒才能注册击键等。所以我们启动 Munin，唯一超出正常范围的是 Mysql 线程数。CPU 使用率低于 1%，负载低于 1.0，可用 RAM 充足。
如前所述，线程数在 2 到 4 之间浮动。在我们速度变慢的时候，线程数飙升到 14。因此，我开始在互联网上搜索，我发现在大多数情况下，当您开始遇到慢查询时，您会看到更高的线程数。如果我理解正确的话，请求需要一段时间才能处理，同时其他请求正在传入，因此将创建一个新线程来处理该请求（是吗？）。但在速度变慢的时候，我们有 0 个慢查询。
我的问题是：还有什么原因会导致 mysql 创建额外的线程。线程突然激增是否会导致服务器变慢？为了解决这个问题，我们重新启动了 apache，一切都恢复正常。考虑到服务器生命体征（CPU、RAM、网络等）都是理想的，线程数是唯一不正常的地方，这似乎是最合乎逻辑的可能原因。
如果重要的话，我们使用的是 Mysql 5.1.40。服务器是 FreeBSD 7.2，有问题的服务器在监狱里。
答案1
根据 Apache 正在执行的操作，大量同时向 Apache 发出的请求可能会导致这种情况。例如，大型 CMS 可能会在早期打开 MySQL 连接，花很长时间生成页面，并且直到完成才关闭连接。
顺便说一句，我发现定期轮询当前连接通常不能反映真实情况。你应该看看最大使用连接数。不幸的是，这个值很难管理：https://dba.stackexchange.com/questions/6040/how-can-i-get-the-maxium-number-of-concurrent-connections-to-mysql-over-a-specif
发生这种情况时，请查看输出，SHOW FULL PROCESSLIST;看看是否有很多进程处于睡眠状态。至少有一个可能导致 MySQL 在 SHOW VARIABLES 上挂起的错误。
答案2
而不是使用：
mysql -e "show global status"|grep -i threads_connected
或者lsof
您可以考虑将procfs其与常见的 GNU/Linux 实用程序一起使用：
find /proc/`pidof mysqld`/fd/ -follow -type s | wc -l
答案3
我来晚了，但最近刚解决了一个类似的问题。如果您碰巧使用的是 MyISAM 存储引擎，并且有一个写入操作，则所有其他读取请求都必须等到表级锁定被释放。如果查询跨越多个表，则会出现两个复杂情况：1. 连接的结果不会全部放入内存中，并且会调用文件排序，这意味着更多的磁盘 I/O。2. 更多的表被锁定，因此读取查询更有可能排队。在大多数情况下，MySQL 将完成写入，读取将清除。如果操作系统无法释放文件的锁定（这种情况发生的频率比您预期的要高），那么 MySQL 线程将被卡住。