MySQL-終わりのないサーバークラッシュクエリの特定
MySQLが原因のOOMエラーが原因でサーバーがクラッシュし続けます。私は、このサイトに間違った、長すぎるクエリがあり、この問題を引き起こしていると確信しています。サーバーとMySQLのログには、スパイクと問題が発生するまでほとんど負担がかかりません。私は本当に、本当にこの問題のあるクエリを特定し、クエリを修正したいと思います。とにかく削除したい悪いクエリを生き残るためにmysqlが他の点では優れた本番サーバーを調整することは、それを回避するための奇妙な方法だと思います。
遅いクエリログを設定していますが、この問題のあるクエリがログに表示されることはありません。クエリが終了しないため、サーバーが最初にクラッシュすると思います。この問題のあるクエリをログに記録または特定するにはどうすればよいですか？
参考までにこのサイトにはこの問題の原因となった他のクエリがあり、それらを特定して修正しました。これらは通常、「BETWEEN :: startTime AND :: endTime」などの句が原因で発生し、誤って:: startTimeが0に設定されていたため、タイムスパンが非常に長くなりました。
EXPLAINを使用するようにアドバイスされましたが、問題は「EXPLAIN」へのクエリがわからないことです:)。
このクエリを特定する方法についての提案をいただければ幸いです。ありがとう！
私はあなたにワイルドな提案があります。
私がDBAStackExchangeに書いた投稿があります プロセスリストをポーリングし、選択した間隔で最もパフォーマンスの低い20のクエリを教えてください 。遅いクエリログは完了したクエリのみを記録するため、これは遅いクエリログよりも優れています。私のメソッドは、現在実行中のクエリを実行中にキャッチします。
私は昨年の半ばにこれを実装しました このYouTubeビデオに基づく 。
他の答えを補足するために、私は Percona Toolkit を指摘します。これはMySQLパフォーマンス分析のための私のツールNo.1です。 pt-query-digest をご覧ください
Percona Toolkitでpt-stalkツールを作成して、探していないときに発生する問題を診断できるようにしました。問題のあるクエリを見つけるのに役立つだけでなく、クエリが問題であるかどうか、そうでない場合は他に何があるかを判断するのに十分な情報を収集します。