このクエリーでは、(key_part1, key_part2) のインデックスにより、オプティマイザはソートを回避できます:

SELECT * FROM t1
  ORDER BY key_part1, key_part2;

ただし、クエリーでは、key_part1 および key_part2 よりも多くのカラムを選択できる SELECT * が使用されます。 その場合、インデックス全体をスキャンしてテーブルの行を検索し、インデックスにないカラムを検索すると、テーブルをスキャンして結果をソートするよりコストがかかる可能性があります。 その場合、オプティマイザはおそらくインデックスを使用しません。 SELECT * がインデックスカラムのみを選択した場合、インデックスが使用され、ソートは回避されます。

t1 が InnoDB テーブルの場合、テーブルの主キーは暗黙的にインデックスの一部であり、インデックスを使用してこのクエリーの ORDER BY を解決できます:

SELECT pk, key_part1, key_part2 FROM t1
  ORDER BY key_part1, key_part2;

このクエリーでは、key_part1 は定数であるため、インデックスを介してアクセスされるすべての行は key_part2 の順序であり、WHERE 句が選択的でテーブルスキャンよりも安価なインデックスレンジスキャンを行うことができる場合、(key_part1, key_part2) のインデックスはソートを回避します:

SELECT * FROM t1
  WHERE key_part1 = constant
  ORDER BY key_part2;

次の 2 つのクエリーでは、インデックスを使用するかどうかが、前述の DESC を使用しない同じクエリーと類似しています:

SELECT * FROM t1
  ORDER BY key_part1 DESC, key_part2 DESC;

SELECT * FROM t1
  WHERE key_part1 = constant
  ORDER BY key_part2 DESC;

ORDER BY の 2 つのカラムは、同じ方向 (ASC または両方の DESC) または反対方向 (ASC、一方の DESC) でソートできます。 インデックスの使用条件は、インデックスの均一性は同じである必要があるが、実際の方向は同じである必要がないことです。

クエリーで ASC と DESC が混在している場合、インデックスで対応する昇順と降順の混合カラムも使用されていれば、オプティマイザはカラムにインデックスを使用できます:

SELECT * FROM t1
  ORDER BY key_part1 DESC, key_part2 ASC;

key_part1 が降順で key_part2 が昇順の場合、オプティマイザは (key_part1、key_part2) のインデックスを使用できます。 key_part1 が昇順で key_part2 が降順の場合は、これらのカラムにインデックスを使用することもできます (バックワードスキャンを使用)。 セクション8.3.13「降順インデックス」を参照してください。

次の 2 つのクエリーでは、key_part1 が定数と比較されます。 インデックスは、テーブルスキャンよりもインデックスレンジスキャンの方が安くなるように、WHERE 句が選択的である場合に使用されます:

SELECT * FROM t1
  WHERE key_part1 > constant
  ORDER BY key_part1 ASC;

SELECT * FROM t1
  WHERE key_part1 < constant
  ORDER BY key_part1 DESC;

次のクエリーでは、ORDER BY は key_part1 を指定しませんが、選択されたすべての行には定数の key_part1 値があるため、インデックスは引き続き使用できます:

SELECT * FROM t1
  WHERE key_part1 = constant1 AND key_part2 > constant2
  ORDER BY key_part2;

このクエリーでは、異なるインデックスで ORDER BY を使用します:

SELECT * FROM t1 ORDER BY key1, key2;

クエリーでは、インデックスの連続していない部分で ORDER BY を使用します:

SELECT * FROM t1 WHERE key2=constant ORDER BY key1_part1, key1_part3;

行のフェッチに使用されるインデックスは、ORDER BY で使用されるインデックスとは異なります:

SELECT * FROM t1 WHERE key2=constant ORDER BY key1;

クエリーでは、インデックスカラム名以外の用語を含む式を使用して ORDER BY を使用します:

SELECT * FROM t1 ORDER BY ABS(key);
SELECT * FROM t1 ORDER BY -key;

クエリーによって多数のテーブルが結合され、ORDER BY のカラムは、行の取得に使用される最初の非定数テーブルのすべてではありません。 (これは EXPLAIN 出力で、const 結合型を持たない最初のテーブルです。)

クエリーの ORDER BY 式と GROUP BY 式が異なります。

ORDER BY 句で指定されたカラムの接頭辞にのみインデックスがあります。 この場合、インデックスを使用してソート順序を完全には解決できません。 たとえば、CHAR(20) カラムの最初の 10 バイトのみがインデックス付けされている場合、インデックスでは 10 バイトを超える値を区別できず、filesort が必要です。

インデックスには、行は順番に格納されません。 たとえば、これは、MEMORY テーブルの HASH インデックスに当てはまります。

sort_buffer_size 変数値を増やします。 理想的には、(ディスクへの書込みおよびマージパスを回避するために) 結果セット全体がソートバッファに収まるように値を十分に大きくする必要があります。

ソートバッファーに格納されているカラム値のサイズは、max_sort_length システム変数値の影響を受けることを考慮してください。 たとえば、タプルに長い文字列カラムの値が格納されていて、max_sort_length の値を増やすと、ソートバッファータプルのサイズも増加し、sort_buffer_size を増やす必要がある場合があります。

(一時ファイルをマージするための) マージパスの数を監視するには、Sort_merge_passes ステータス変数を確認します。

一度に読み取られる行が増えるように、read_rnd_buffer_size 変数の値を増やします。

tmpdir システム変数を変更して、大量の空き領域のある専用ファイルシステムを指すようにします。 変数値には、ラウンドロビン方式で使用される複数のパスをリストできます。この機能を使用して、複数のディレクトリに負荷を分散できます。 パスは、Unix ではコロン文字 (:) で区切り、Windows ではセミコロン文字 (;) で区切ります。 パスには、同じディスク上の異なるパーティションではなく、異なる物理ディスクにあるファイルシステム内のディレクトリを指定してください。

EXPLAIN 出力の Extra カラムに Using filesort が含まれていない場合、インデックスが使用され、filesort は実行されません。

EXPLAIN 出力の Extra カラムに Using filesort が含まれている場合、インデックスは使用されず、filesort が実行されます。

<sort_key, rowid> : これは、ソートバッファータプルが、元のテーブル行のソートキー値と行 ID を含むペアであることを示します。 タプルはソートキー値でソートされ、行 ID は、テーブルからの行の読み取りに使用されます。

<sort_key, additional_fields> : これは、ソートバッファータプルにソートキー値とクエリーによって参照されるカラムが含まれていることを示します。 タプルはソートキー値でソートされ、カラム値は、タプルから直接読み取られます。

<sort_key, packed_additional_fields> : 前のバリアントと同様ですが、追加のカラムは固定長エンコーディングを使用するかわりに密接にパックされます。