私は次のことを言うサンプル構成ファイルから読みました:
# Sort buffer is used to perform sorts for some ORDER BY and GROUP BY
# queries. If sorted data does not fit into the sort buffer, a disk
# based merge sort is used instead - See the "Sort_merge_passes"
# status variable. Allocated per thread if sort is needed.
Filesortを使用するクエリがいくつかあります。クエリがディスクにアクセスせずにスムーズに実行するために必要なバッファのサイズを判断するにはどうすればよいですか?
sort_buffer_size に関係するステータス変数は1つだけです。それが質問のメッセージにあるものです: Sort_merge_passes 。 MySQLのドキュメントは言う:
Sort_merge_passes:ソートアルゴリズムが実行しなければならないマージパスの数。この値が大きい場合は、システム変数 sort_buffer_size の値を増やすことを検討してください。
sort_buffer_size について1つ注意してください
SHOW GLOBAL STATUS出力に毎秒多くのSort_merge_passesが表示される場合は、sort_buffer_sizeの値を増やして、クエリの最適化または改善されたインデックス作成では改善できないORDER BYまたはGROUP BY操作を高速化することを検討できます。
育てながらsort_buffer_size
はGROUP BY
砂 ORDER BY
s、改善できるクエリを改善し、クエリオプティマイザーで使用できるインデックスを追加することをお勧めします。
質問は残ります: Sort_merge_passes ???
このコードを使用して、過去5分間に発生したSort_merge_passesの数を確認します。また、1時間あたりのSort_merge_passesも計算します。
SET @SleepTime = 300;
SELECT variable_value INTO @SMP1
FROM information_schema.global_status WHERE variable_name = 'Sort_merge_passes';
SELECT SLEEP(@SleepTime) INTO @x;
SELECT variable_value INTO @SMP2
FROM information_schema.global_status WHERE variable_name = 'Sort_merge_passes';
SET @SMP = @SMP2 - @SMP1;
SET @SMP_RATE = @SMP * 3600 / @SleepTime;
SELECT @SMP,@SMP_RATE;
Sort_merge_passesとレートが高すぎる場合は、自由に sort_buffer_size を増やしてください。 4Mにレイズしたいとします。あなたはこれを実行します:
mysql> SET GLOBAL sort_buffer_size = 1024 * 1024 * 4;
次に、これをmy.cnfに追加します
[mysqld]
sort_buffer_size = 4M
コードを定期的に実行して、他の時間をチェックします Sort_merge_passes スパイク。
マニュアル(5.0-5.5)のガイダンスは
SHOW GLOBAL STATUS出力に毎秒多くのSort_merge_passesが表示される場合は、sort_buffer_size値を増やして、クエリの最適化または改善されたインデックス付けでは改善できないORDER BYまたはGROUP BY操作を高速化することを検討できます。バッファ全体が必要でない場合でも、全体が割り当てられるため、バッファをグローバルに必要以上に大きく設定すると、ソートを行うほとんどのクエリの速度が低下します。セッション設定として、より大きなサイズを必要とするセッションに対してのみ、値を増やすことをお勧めします。 Linuxでは、256KBと2MBのしきい値があり、値が大きいとメモリ割り当てが大幅に遅くなる可能性があるため、これらの値のいずれかを下回ったままにすることを検討する必要があります。実験して、ワークロードに最適な値を見つけてください。
5.6以降、この表現は、オプティマイザがクエリの値を選択でき、サーバーがバッファを制限まで拡張できることを示しています。これにより、値を高く設定しすぎるコストが軽減されます。ですから、5.6.4未満のリリースでは(リリースのcnfファイルと同じように)デフォルトよりも控えめにした方がいいように思えますが、5.6からデフォルトの2MB以上の上限を設定する余裕があります。全額が盲目的に割り当てられていないため、4。
MySQL 5.6.4の時点で、オプティマイザは必要なスペースを計算しようとしますが、上限までさらに割り当てることができます。
Sort_buffer_sizeをデフォルトから変更する必要はありません。質問に基づいてそれが使用されていると誤解している。最初にSQLを調べて、SQLを調整し、インデックスを使用してORDER BY/GROUP BY条件を満たすことができるかどうかを確認する必要があります。通常は複合インデックスになります。
さらに: http://www.xaprb.com/blog/2010/05/09/how-to-tune-mysqls-sort_buffer_size/
最適なsort_buffer_size
を決定する最良の方法は、それをベンチマークすることです。
どうやって? @RolandoMySQLDBAのように、Sort_merge_passes
のチェックは役立つかもしれませんが、パフォーマンスに影響を与えるのはそれだけではありません。 sort_buffer_size
を増やすときは注意が必要です。
ドキュメント は
Linuxでは、256KBと2MBのしきい値があり、値が大きいとメモリ割り当てが大幅に遅くなる可能性があるため、これらの値のいずれかを下回ったままにすることを検討する必要があります。
それを結論付けるテストについて 投稿 があります
sort_merge_passes
はそれほど悪くありません。sort_buffer_size
がゼロになるようにsort_merge_passes
を十分に大きく設定すると、最適ではない可能性があります。
テストしたところ、同様の結果が得られました。
理想的には、sort_buffer_size
を最適化する必要がある状況を回避することが最善です。どうやって? このORDER BY最適化ドキュメント は、内部での動作を理解するのに役立ちます。