我有间歇性的发生的MySQL造成高负荷的机器，使Web应用程序不可用。 我正在使用monit来监视它，但它不能解决问题，显然是因为它仍然可以连接到mysql。 这是我的monit脚本为mysql：
check process mysqld with pidfile /var/run/mysqld/mysqld.pid group database start program = "/etc/init.d/mysql start" stop program = "/etc/init.d/mysql stop" if failed port 3306 protocol mysql then restart if failed unixsocket /var/run/mysqld/mysqld.sock protocol mysql then restart if 5 restarts within 5 cycles then timeout 当问题发生在机器上的负载是很高，用MySQL几乎所有的CPU。 您仍然可以使用mysql命令行工具“login”到mysql，但是任何select/更新都不会响应。
当这个问题出现时，我应该用什么来捕捉？
通过MySQL客户端检查stream程列表。 （ show full processlist; ）从这一点上，你可以隔离查询运行的地方，是否需要优化或是否应该停止。
从这一点上，你可以kill $NUMBER; 终止问题连接，而不是重新启动MySQL。
重新启动由于不希望的操作而已经运行的应该是最后的手段，通常是一个坏主意。 特别是对于数据库，因为您冒着数据的风险。
当然，具体情况决定了不同的行动。 例如，如果您知道在特定软件中存在失控的内存泄漏，则没有任何操作正在运行，并且恢复资源的唯一方法是重新启动：然后执行此操作。
另外，如果你每分钟都损失很多钱，重启可能是合理的。 例如，如果您看不到快速恢复的path，并且您认为重新启动将恢复服务，那么如果数据或应用程序的风险比您正在失败的风险更less，则重新启动将会有意义。 这个原则适用，但可能会有所不同，取决于您的行业，服务和SLA。
它可能是locking表或超载的服务器。 尝试慢查询日志logging，以及华纳的processlist的build议（小贴士：mytop会在一个方便的界面中做到这一点）。 也可以尝试（常规），查看与数据库竞争CPU的情况。
如果你看到高负载（运行队列），而没有进程吃（很多）的CPU功率，它可能是存储相关的。 （IOPS /吞吐量不足）