MySQL がソートをどのように処理するかについて話しましょう

オープンソースの中国コミュニティチームは、共有の名のもとに、オープンソースの中国コミュニティの背後にあるストーリーを伝える初のライブブロードキャストを行いました。」

この記事は、Huawei Cloud Community「MySQL はソートをどのように処理しますか⭐️ソートが必要なクエリを最適化するには?」から共有されたものです。 "、著者: Caicai のバックエンドのプライベートキッチン。

序文

これら 2 つのキーワードはMySQL クエリでよく使用されます。 order by group by

これらの共通点は、フィールドを並べ替えることです。では、クエリステートメントでの並べ替えはどのように実装されるのでしょうか。

使用されるクエリステートメントを並べ替える必要がある場合の処理状況は 2 つあります。

現在のレコードは本質的に順序付けされているため、並べ替える必要はありません。
現在のレコードは順序を維持していないため、並べ替える必要があります

インデックスを使用して順序を確実にする

最初のケースでは、ソートが必要ないように、結果セットの順序を保証するためにセカンダリインデックス内のインデックス列の順序がよく使用されます。

テーブル a に対して、a2 のセカンダリインデックスを作成すると、a2 はセカンダリインデックスで順序付けされます。

テーブル `a` を作成 (
   `a1` int(11) NOT NULL AUTO_INCREMENT、
   `a2` varchar(255) 文字セット utf8mb4 デフォルト NULL、
   `a3` varchar(255) デフォルト NULL、
   主キー (`a1`)、
   キー `idx_a2` (`a2`)
 ) ENGINE=InnoDB AUTO_INCREMENT=76 DEFAULT CHARSET=utf8;

select * from a order by a.a2 limit 10

オプティマイザが a2 インデックスの使用を選択すると、a2 列のレコード自体が順序付けされるため、並べ替えに他のオーバーヘッドを使用する必要はありません。

画像.png

もちろん、オプティマイザは a2 インデックスを使用しない場合があります (オプティマイザは、テーブルを返すために a2 を使用するのはコストが高すぎると判断した場合、テーブル全体のスキャンを使用します)。

画像.png

オプティマイザが使用するインデックスで a2 の順序が正しくない場合、結果は他の手段で並べ替えられます。

ファイルソート

実行計画の追加情報が表示される場合、sort_buffer を使用して結果をソートします。 Using filesort

sort_buffer は並べ替えに使用されるメモリの一部で、クエリに必要なすべてのフィールドを格納することも、並べ替えが必要なフィールドと主キーのみを格納することもできます。

show variables like 'max_length_for_sort_data'

クエリで必要なフィールドの長さが 1 未満の場合、クエリで必要なすべてのフィールドが sort_buffer に配置され、その後、並べ替えが必要な列が並べ替えられ、最後に結果が返されます。 max_length_for_sort_data

画像.png

クエリに必要なフィールドの長さがフィールドの長さよりも長い場合、並べ替える必要があるフィールドと主キー値のみが sort_buffer に配置され、クラスタ化インデックスがクエリされて、並べ替え後にクエリする必要がある列 (テーブルにもう 1 回戻ることに相当) max_length_for_sort_data

画像.png

sort_buffer でソートする場合、メモリが十分にある場合はメモリ内でソートが行われます。メモリが十分でない場合は、ディスク上の一時ファイルがソートを補助するために使用されます。

これをオンにすると、並べ替えを支援するために一時ファイルが使用されるかどうかが確認されます。 optimizer_trace

#オプティマイザの追跡を有効にする
 SET optimizer_trace='enabled=on';
 
 #sqlstatement
 select * from students order bystudent_name 制限 10000;
 
 #オプティマイザーによって追跡された情報を表示する
 SELECT * FROM `information_schema`.`OPTIMIZER_TRACE`\G;

ソートに使用されるアルゴリズムはマージアルゴリズムです。最初に複数の小さなファイルに分割され、ソートされてからマージされます。

ここで、number_of_tmp_files は使用される一時ファイルの数、sort_buffer_size はsort_bufferのサイズです。

画像.png

したがって、order by、group by、および並べ替えが必要なその他のキーワードを使用する場合は、適切なインデックスを確立することが最善です。

データの量が少ない場合は、ソートバッファーでソートできます。データの量が多すぎる場合は、ディスクと対話する必要があります。

要約する

クエリステートメントを並べ替える必要がある場合、並べ替えを行わない場合と並べ替えが必要な場合の 2 つの状況に分けられます。

使用されるインデックスが適切であれば、ソートする必要はなく、インデックスによって順序が保証されます。

使用されるインデックスが間違っている場合、sort_buffer がソートに使用されます。クエリフィールドの長さが制限を超えない場合、sort_buffer の各レコードにはクエリが必要な列が格納されます。

制限を超えた場合、sort_buffer は並べ替えが必要な列と主キー値のみを保存します。並べ替え後、主キー値はクエリが必要な列を取得するためにテーブルを返すために使用されます。

データ量が大きすぎてメモリ内で並べ替えられない場合は、並べ替えを支援するためにディスクページが使用され、並べ替えられたデータを複数のページに分散してマージするためにマージアルゴリズムが使用されます。

トレースオプティマイザー optimizer_trace を使用してコンテンツを分析し、補助ページの数やその他の情報を表示できます。

ディスクページ支援ソートの使用を避けるために、ソートが必要な列に適切なインデックスを作成します。

インデックス作成が使用できない場合は、ソートバッファーまたは max_length_for_sort_data を調整できます (注意が必要です)。

クリックしてフォローし、できるだけ早くHuawei Cloudの新しいテクノロジーについて学びましょう~