最近，我们的一台服务器内存不足并崩溃了。查看图表后munin，似乎崩溃前唯一达到峰值的指标（内存使用率除外）是MySQL throughput。然而，我们原本预计会看到 的数量相应增加，但MySQL queries事实并非如此：
另外，从下图中你可以看到已经MySQL throughput达到了一个异常高的值，远不及之前达到的任何其他值：
我们完全不知道应该如何进行，因此提出以下问题：
如何对 MySQL 吞吐量增加进行“事后”调查？
答案1
具有巨大结果集的查询会导致这样的峰值，但查询量并没有相应增加。您是否有任何磁盘 I/O 监控？如果这是由查询引起的，那么也应该会出现很大的峰值。
不幸的是，如果不启用，事后检查会很困难general_log。错误日志不会显示成功执行的查询。
接下来，我尝试捕捉这些问题的方法是保留一个查询日志窗口。启用general_log并设置 logrotate 以保留查询的简要历史记录。如果这对性能要求太高，您还可以尝试使用 mk-query-digest 等工具与 tcpdump 一起捕获查询。