MySQLスループットのピークを調査する方法は？
最近、サーバーの1つでメモリが不足し、クラッシュしました。 muninグラフを確認したところ、クラッシュの直前にピークに達した唯一のメトリック（メモリ使用量以外）はMySQL throughputであったようです。ただし、対応するMySQL queriesの数の増加が見られると予想していましたが、これは発生しませんでした。
また、下のグラフから、MySQL throughputが異常に高い値に達しており、以前に到達した他の値にはほど遠いことがわかります。
私たちはどのように進めるべきかについて完全に暗闇にいるので、以下の質問があります：
MySQLスループットの増加の「事後」調査を実行する方法は？
膨大な結果セットを持つクエリは、クエリの量の対応する増加を見ることなく、そのようなスパイクを引き起こします。ディスクI/Oモニタリングはありますか？これがクエリによって引き起こされた場合は、その中にも大きなスパイクがあるはずです。
残念ながら、general_logを有効にしないと死後検査は困難です。エラーログには、正常に実行されたクエリは表示されません。
今後、これらの問題を解決するために私が行ったことは、クエリログのウィンドウを保持することです。 general_logを有効にし、logrotateを設定して、クエリの簡単な履歴を保持します。パフォーマンスが高すぎる場合は、mk-query-digestなどのツールをtcpdumpと一緒に使用してクエリをキャプチャすることもできます。