MySQL は降順インデックスをサポートしています: インデックス定義内の DESC は無視されなくなりましたが、キー値が降順で格納されます。 以前は、インデックスを逆の順序でスキャンできましたが、パフォーマンスが低下していました。 降順インデックスは順にスキャンできるため、より効率的です。 降順インデックスを使用すると、オプティマイザが複数カラムインデックスを使用できるようになります (最も効率的なスキャン順序で一部のカラムに昇順が混在し、他のカラムに降順が混在している場合)。
カラムの昇順インデックスと降順インデックスの様々な組合せに対する 2 つのカラムと 4 つの 2 カラムインデックス定義を含む、次のテーブル定義について考えてみます:
CREATE TABLE t (
c1 INT, c2 INT,
INDEX idx1 (c1 ASC, c2 ASC),
INDEX idx2 (c1 ASC, c2 DESC),
INDEX idx3 (c1 DESC, c2 ASC),
INDEX idx4 (c1 DESC, c2 DESC)
);
テーブル定義の結果、4 つの個別インデックスが作成されます。 オプティマイザは、各 ORDER BY 句に対して正引きインデックススキャンを実行できるため、filesort 操作を使用する必要はありません:
ORDER BY c1 ASC, c2 ASC -- optimizer can use idx1
ORDER BY c1 DESC, c2 DESC -- optimizer can use idx4
ORDER BY c1 ASC, c2 DESC -- optimizer can use idx2
ORDER BY c1 DESC, c2 ASC -- optimizer can use idx3降順インデックスの使用には、次の条件があります:
-
降順インデックスは
InnoDBストレージエンジンでのみサポートされますが、次の制限があります:インデックスに降順のインデックスキーカラムが含まれている場合、または主キーに降順のインデックスカラムが含まれている場合、変更バッファリングはセカンダリインデックスではサポートされません。
InnoDBSQL パーサーは降順インデックスを使用しません。InnoDB全文検索の場合、これは、インデックス付きテーブルのFTS_DOC_IDカラムに必要なインデックスを降順インデックスとして定義できないことを意味します。 詳細は、セクション15.6.2.4「InnoDB FULLTEXT インデックス」を参照してください。
降順インデックスは、昇順インデックスが使用可能なすべてのデータ型でサポートされています。
降順インデックスは、通常の (生成されない) カラムおよび生成されるカラム (
VIRTUALとSTOREDの両方) でサポートされます。DISTINCTでは、降順のキー部分など、一致するカラムを含む任意のインデックスを使用できます。降順のキー部分を持つインデックスは、集計関数を呼び出すが
GROUP BY句を持たないクエリーのMIN()/MAX()最適化には使用されません。-
降順インデックスは
BTREEではサポートされていますが、HASHインデックスではサポートされていません。 降順インデックスは、FULLTEXTまたはSPATIALインデックスではサポートされていません。HASH、FULLTEXTおよびSPATIALインデックスに対して明示的に指定されたASCおよびDESCの指定では、エラーが発生します。