2

MySQLサーバーでの遅いクエリの問題をデバッグしています。クエリは通常100〜400ミリ秒で完了しますが、場合によっては数十秒または数百秒に急上昇します。

クエリは、私が制御できないアプリケーションによって生成され、複数のデータベースがあります（顧客ごとに1つ）。遅いクエリはランダムに表示されるようで、遅いクエリがログに記録されると、RAM、ディスク、CPUのいずれもロードされません。クエリを手動で実行すると、（ミリ秒単位で）正常に実行されるため、他の読み取りおよび書き込みクエリと組み合わせたロックの問題が疑われます。クエリ自体はひどいです（WHERE句またはORDER BY句のいずれかでインデックスを使用できません）が、最大のテーブルは比較的小さく（最大200.000行）、JOINはほとんどありません。クエリのプロファイルを作成すると、ほとんどの時間が結果の並べ替えに費やされます（クエリが正常に実行される場合）。

テスト環境で極端な速度低下を再現することはできません。現時点での最善のアイデアは、本番MySQLサーバーを停止し、データベースのコピーを作成し、完全なクエリロギングを有効にして、サーバーを再起動することです。このようにして、ロードを再生して問題を再現できるはずです。ただし、一般的なクエリログには、クエリのターゲットデータベースではなく、クエリのみが記録されているようです。MySQL用の他の記録/再生オプションはありますか？

4

3 に答える 3

1

遅いクエリログを使用できます：http：//dev.mysql.com/doc/refman/5.1/en/slow-query-log.html

しきい値を非常に小さい値に設定するだけです（うまくいけば、mysql> 5.1を実行しています）

それ以外の場合は、tcpdumpを使用できます： http ：//www.mysqlperformanceblog.com/2008/11/07/poor-mans-query-logging/

もちろん、それを使用する場合は、perconaツールキットのpt-query-digestを調べて、tcpdump出力を処理することをお勧めします。http：//www.percona.com/doc/percona-toolkit/2.1/pt-query- digest.html

今後の参考のために、クエリとサーバーの監視を設定することをお勧めします： https ://github.com/box/Anemometer/wiki および https://github.com/box/RainGauge/wiki/What-is-Rain-Gauge ％3F

于 2012-09-04T22:14:13.090 に答える
0

私はついに問題を突き止めました。アプリケーションは次のようなことをしています。

cursor = conn.execute("SELECT * FROM `LargeTable`")
while cursor.has_more_rows():
  cursor.fetchrow()
  do_something_that_takes_a_while()
cursor.close()

一度に1行ずつ、結果セットをフェッチして処理します。ループが完了するまでに100秒かかる場合、テーブルはサーバー上で100秒間ロックされます。

MySQLサーバーでこの設定を変更する：

set global SQL_BUFFER_RESULT=ON;

結果セットが一時テーブルにプッシュされるようになったため、アプリケーションが結果セットをどれだけゆっくりと消費するかに関係なく、テーブルロックを削除できるため、遅いクエリがすぐに消えるようになりました。この設定により、他にも多くのパフォーマンスの問題が発生しますが、幸いなことに、サーバーはこれらの問題を処理できるように設計されています。

于 2012-09-07T12:22:48.000 に答える
0

PerconaはPlaybackと呼ばれる新しいツールに取り組んでおり、これはまさにあなたが望むことを実行します： http ://www.mysqlperformanceblog.com/2013/04/09/percona-playback-0-6-for-mysql-now-available/

于 2013-05-01T01:18:07.530 に答える