MySQL Order Byインデックス最適化方法

ORDER BYはインデックスの順序と正確に一致していないにもかかわらず、インデックスはまだ使用されてもよく、不要なインデックス部分と追加のORDER BYフィールドはWHEREサブルーチンに含まれています。インデックスを使用するMySQL Order By以下のいくつかのクエリは、インデックスを使用して、ORDER BYまたはGROUTP BY部分を解決します。

 
SELECT * FROM t1 ORDER BY key_part1,key_part2,... ; 
SELECT * FROM t1 WHERE key_part1=constant ORDER BY key_part2; 
SELECT * FROM t1 WHERE key_part1=constant GROUP BY key_part2; 
SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 DESC; 
SELECT * FROM t1 WHERE key_part1=1 ORDER BY key_part1 DESC, key_part2 DESC; 

はインデックスを使用しないMySQL Order Byは別の場合、MySQLはインデックスを使用してORDER BYを満たすことができません。これらの場合、*異なるインデックスキーに対してORDER BY:SELECT*FROM 1 ORDER BY key 1,key 2;連続しないインデックスキー部分にORDER BYをする：SELECT*FROM 1 WHERE key 2=constant ORDER BY key_パーティー2;ASCとDESCを同時に使用しました。SELECT*FROM 1 ORDER BY key_part 1 DESC、key_part 2 ASC;*検索記録用のインデックスキーとORDER BYをするのは同じではありません。SELECT*FROM 1 WHERE key 2=constant ORDER BY key 1;*多くのテーブルが一緒に接続されています。また、ORDER BYのフィールドはすべて最初の非常数のテーブルから来ているわけではありません。つまり、EXPLAN分析の結果、最初のテーブルの接続タイプはconstではありません。ORDER BYとGROUT BYの異なる表現を使用しました。＊表索引の記録は、順番に保存されていません。例えば、HASHとHEAP表はこうです。EXPLAN SELECT...ORDER BYを実行することで、MySQLがクエリにインデックスを使用しているかどうかが分かります。Extraフィールドの値がUsing filesortである場合、MySQLはインデックスを使用できないことを示しています。詳細は「7.2.1 EXPLAN Syntax（Get Information About a SELECT）」をご覧ください。結果を並べ替える必要がある場合、MySQL 4.1は、以前に以下のfilesortアルゴリズムを使用していた。

 
1.          ，       。       WHERE           。 
2.             ‘ '   2  （        ）。            sort_buffer_size     。 
3.       ，    qsort（    ）            。           （     ‘ '         ，          ）。 
4.        ，             。 
5.        ，    MERGEBUFF（7）                。      ，                     。 
6.       ，           MERGEBUFF2 (15)。 
7.           ，       （          ）        。 
8.                      。        ，MySQL               ，            ，        。           read_rnd_buffer_size     。            `sql/records.cc'  。 

この近似アルゴリズムの問題は、データベースが2回の記録を読み込みました。一回はWHEREセグメントを推定するとき、2回目は並べ替え時です。一回目は記録を読み込みましたが、二回目はランダムに読みました。MySQL 4.1および更新されたバージョンでは、filesort最適化アルゴリズムは、インデックスキーとレコードの位置だけでなく、クエリに必要なフィールドを含む記録に使用されます。このようにすると、記録を2回読み込む必要があります。修正したfilesortアルゴリズムの作り方は大体以下の通りです。2.各記録に対して、対応するものを記録しました。タプル'情報には、索引キー、レコード位置、およびクエリに必要なすべてのフィールドが含まれます。3.索引キーに基づいて‘元グループ’の情報を並べ替えます。4.記録を順番に読み込みます。並べ替えられた「元グループ」リストから記録を読み取ります。データテーブルからもう一度読み込むのではありません。改良されたfilesortアルゴリズムを使って、元のものに比べて、「元のグループ」は「対」よりもっと長い空間を占有する必要があります。それらはほとんど順序バッファに適合していません。ブザーsizeの値が決められています）。従って，これはより多くのI／O動作が必要となり，改良アルゴリズムがより遅くなる可能性がある。遅くならないようにするために、この最適化方法は「元のグループ」に追加されたフィールドのサイズの合計がシステム変数max_を超えて並べ替えられます。レングス.for_sort_dataの場合（この変数の値が高すぎるように設定されているイメージは、高ディスク負荷低CPU負荷である）。ORDER BYの速度を上げるには、まずMySQLが追加のソートプロセスではなくインデックスを使用できるかどうかを確認します。インデックスが使えない場合は、以下のポリシーに従ってみてください。*ソートを追加します。ブザーsizeの値*read_を追加しますrnd_ブザーsizeの値*tmpdirを修正して、多くの空きスペースがある専用ファイルシステムを指します。MySQL 4.1または更新を使用すると、このオプションは複数のパスを循環形式で使用することができます。各パスの間はUnix上でコロン(':')で区切られており、Windows、NetWareおよびOS/2上でセミコロン(')。この特性を利用して、負荷をいくつかのディレクトリに均等に割り当てることができます。これらのパスは、同じ物理ディスク上の異なるディレクトリではなく、異なる物理ディスク上に分布しているディレクトリでなければなりません。