system

1 レコードのみで構成されるテーブル (= システムテーブル)。これは、const 結合型の特殊なケースである。

const

テーブルに、一致するレコードが最大で 1 つあり、クエリーの開始時に読み取られる。レコードが 1 つしかないため、このレコードのカラムの値はオプティマイザによって定数と見なされます。const テーブルは、1 回しか読み取られないため、非常に高速です。

const は PRIMARY KEY/UNIQUE キーを定数と比較する場合に使用される。下記のクエリーでは、tbl_name は const テーブルとして使用できる。

SELECT * FROM tbl_name WHERE primary_key=1;
SELECT * FROM tbl_name
  WHERE primary_key_part1=1 AND primary_key_part2=2;

eq_ref

前のテーブルのレコードの組み合わせのそれぞれに対して、このテーブルから 1 レコードずつ読み取られる。これは、system と const 型以外で最適な結合型である。結合でインデックスのすべての部分が使用され、このインデックスが UNIQUE または PRIMARY KEY である場合に使用される。

=演算子と比較されるインデックスの張られたカラムには、eq_ref を使用できる。比較対象のアイテムは定数でも、このテーブル以前に読み取られたテーブルのカラムを使用する式でもかまわない。下記の例では、ref_table で eq_ref が使用される。

SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column=other_table.column;
SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column_part1=other_table.column
  AND ref_table.key_column_part2=1;

ref

前のテーブルのレコードの組み合わせのそれぞれに対して、一致するインデックス値を持つすべてのレコードがこのテーブルから読み取られます。ref は、インデックスの左端の接頭辞のみが結合で使用される場合、またはインデックスが PRIMARY KEY や UNIQUE インデックスではない場合 (すなわち、この結合において、インデックス値から 1 つのレコードを SELECT できない場合) に使用されます。この結合型は、使用されるインデックスと一致するレコードが数レコードしかない場合に適している。

=あるいは<=>演算子と比較されるインデックスの張られたカラムには、ref を使用できる。下記の例では、MySQL は ref_table で ref が使用される。

SELECT * FROM ref_table WHERE key_column=expr;
SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column=other_table.column;
SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column_part1=other_table.column
  AND ref_table.key_column_part2=1;

fulltext

FULLTEXT インデックスを使用して結合が実行されます。

ref_or_null

ref と同様だが、NULL を使用したレコードの補足検索も追加で実行される。この結合型の最適化は主としてサブクエリーを解決する場合に使用される。下記の例では、MySQL は ref_table で ref_or_null が使用される。

SELECT * FROM ref_table
  WHERE key_column=expr OR key_column IS NULL;

項4.2.8. 「IS NULL 最適化」 を参照してください。

index_merge

この結合型はインデックス併合最適化が使用されたことを示しています。この場合、出力行の key カラムは使用されたインデックスのリストが含まれ、key_len には使用されたインデックスの最長キーパートが含まれます。詳細は 項4.2.6. 「インデックス結合最適化」 をご覧ください。

unique_subquery

この型は、下記のフォームで IN サブクエリーの代わりに、ref を使用します。

value IN (SELECT primary_key FROM single_table WHERE some_expr)

unique_subquery は、効率化のためサブクエリーの代わりをつとめるインデックスルックアップ関数です。

index_subquery

この結合型は unique_subquery に似ています。IN サブクエリーの代わりに使用されますが、次の形式のサブクエリーで一意でないインデックスで使用できます。

value IN (SELECT key_column FROM single_table WHERE some_expr)

range

インデックスを使用して、一定の範囲にあるレコードのみが取り出される。key カラムに使用されるインデックスが示される。key_len_には使用される最長のインデックス部分が記載される。この型では ref カラムが NULL になる。

range は、=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN、または IN() を使用してキーカラムを定数と比較する場合に使用できます。

SELECT * FROM tbl_name
  WHERE key_column = 10;
SELECT * FROM tbl_name
  WHERE key_column BETWEEN 10 and 20;
SELECT * FROM tbl_name
  WHERE key_column IN (10,20,30);
SELECT * FROM tbl_name
  WHERE key_part1= 10 AND key_part2 IN (10,20,30);

index

これは、インデックスツリーのみがスキャンされる点を除いて ALL と同じである。一般にインデックスファイルはデータファイルより小さいため、通常は ALL より高速である。

MySQL は、クエリーで 1 インデックスの構成部分であるカラムのみが使用される場合にのみ使用できます。

ALL

前のテーブルのレコードの組み合わせのそれぞれに対して、フルテーブルスキャンが実行される。一般に、テーブルが const の指定がない第 1 テーブルの場合には適さず、その他の場合はすべて非常に不適である。通常は、さらにインデックスを追加することで ALL を回避し、定数値または以前のテーブルのカラム値を基準にレコードを取り出すようにすることができる。

Distinct

マッチした最初のレコードが検索されると、MySQL は現在のレコードの組み合わせによるその後のレコード検索を続行しないことを示す。

Full scan on NULL key

これは、オプティマイザでインデックス検索アクセスメソッドを使用できない場合の代替方針として、サブクエリーの最適化に使用されます。

const tables を読んだ後 Impossible WHERE 発見

MySQL はすべての const (あと、system) テーブルを読んだ後、WHERE 節が常に偽となります。

No tables

クエリーには FROM 節がないか、FROM DUAL 節があります。

Not exists

MySQL でクエリーに対する LEFT JOIN 最適化が実行でき、LEFT JOIN に一致するレコードが 1 つ検索されると、前のレコードの組み合わせによるその後のテーブルのレコードについては調べないことを示す。このように最適化できるクエリーの例を次に示します。

SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id
  WHERE t2.id IS NULL;

t2.id が NOT NULL で定義されているとする。この場合、MySQL で t1 がスキャンされ、t1.id で t2 内のレコードのルックアップが行われる。MySQL によって t2 内のマッチするレコードが検索されると、t2.id は NULL ではないと認識され、t2 内の同じ id を持つ残りのレコードのスキャンは行われない。言い換えると、t2 にあるマッチするレコードの数に関わらず、MySQL で実行が必要なことは t1 のレコードのそれぞれに対して、t2 のルックアップを 1 回実行することだけである。

Range checked for each record (index map: N)

MySQL で使用に適した実際のインデックスを検索できなかったことを示す。代替として、先行テーブルのレコードの組み合わせのそれぞれに対して、使用するインデックス (存在する場合)range または index_merge の確認が実行され、このインデックスがテーブルからのレコードの取り出しに使用される。非常に高速ではないが、インデックスなしの結合と比較すると高速である。適用基準は項4.2.5. 「Range 最適化」と項4.2.6. 「インデックス結合最適化」で説明されています。ただし、これは前テーブルのすべてのカラム値が知られており、定数であるという前提においてです。

インデックスには、テーブルの SHOW INDEX で表示されるのと同じ順序で 1 から番号がふられます。インデックスマップ値 N は、どのインデックスが対象になるかを示すビットマスク値です。たとえば、0x19 (2 進数の 11001) という値は、インデックス 1、4、および 5 が対象になることを示します。

Scanned N databases

サーバーが INFORMATION_SCHEMA テーブルのクエリーを処理する際に実行するディレクトリスキャンの数を示します。詳細については、項4.2.20. 「INFORMATION_SCHEMA 最適化」を参照してください。N の値は 0、1、または all です。

Select tables optimized away

クエリーは MyISAM 用に、インデックスで解決された集約ファンクション (MIN()、MAX()) そして COUNT(*) があり、GROUP BY 節は含みませんでした。オプティマイザは 1 つの行のみが返されるべきと判断しました。

Skip_open_table、Open_frm_only、Open_trigger_only、Open_full_table

これらの値は、INFORMATION_SCHEMA テーブルのクエリーに適用する、ファイルを開く処理の最適化を示します。詳細については、項4.2.20. 「INFORMATION_SCHEMA 最適化」を参照してください。

Using filesort

レコードをソートして取り出す方法を決定するには、MySQL はパスを余分に実行しなくてはならないことを示す。join type に従ってすべてのレコードをスキャンし、WHERE 条件に一致するすべてのレコードに、ソートキー + 行ポインタを格納して、ソートは実行される。その後キーがソートされる。最後に、ソートされた順にレコードが取り出される。項4.2.13. 「ORDER BY 最適化」 を参照してください。

Using index

インデックスツリーの情報のみを使用してカラム情報がテーブルから取り出され、実際の行を読み取るその後の検索を実行する必要がないことを示す。この方針は、クエリーで単一のインデックスの構成部分であるカラムのみが使用される場合に使用できます。

ユーザー定義のクラスタ化されたインデックスを持つ InnoDB テーブルの場合、そのインデックスは Extra カラムに Using index がない場合でも使用できます。type が index で key が PRIMARY の場合はこれに当てはまります。

Using index for group-by

Using index テーブルアクセスメソッドに似て、Using index for group-by は MySQL が余分なディスクアクセスを実際のテーブルに行うことなく、GROUP BY または DISTINCT クエリーのカラムをすべて取得することができるインデックスを見つけたことを意味します。加えて、インデックスは各グループにとってもっとも効率的に使われるので、数種類のインデックスしか読まれません。詳細については、項4.2.14. 「GROUP BY 最適化」をご参照ください。

Using join buffer

それまでに結合されたテーブルは部分ごとに結合バッファーに読み込まれ、それらのバッファー内の行を使用して、現在のテーブルとの結合が実行されます。

Using sort_union(...)、Using union(...)、Using intersect(...)

これらは index_merge 結合型でインデックススキャンがどのように併合されるかを示しています。項4.2.6. 「インデックス結合最適化」 を参照してください。

Using temporary

クエリーの解決に MySQL で結果を保持する一時テーブルの作成が必要であることを示す。これは一般に、GROUP BY を実行したカラムセットと異なるカラムセットに対して ORDER BY を実行した場合に発生する。

Using where

次のテーブルとの一致が調べられるレコードまたはクライアントに送信されるレコードの限定に WHERE 節が使用されることを示す。この情報がなく、Extra の値が Using where ではなく、テーブルの型が ALL または index である場合はクエリーが正常に実行されないことがある (テーブルのすべてのレコードの取得や検査を意図していない場合)。

Using where with pushed condition

このアイテムは NDBCLUSTER テーブルにのみ適用されます。それは、MySQL Cluster がコンディションプッシュダウン最適化を使用して、インデックスのないカラムと定数の直接比較の効率化を図ることを意味します。そのような場合、条件はクラスタのデータノードに 「プッシュダウン」 され、すべてのデータノードで同時に評価されます。これは一致しない行をネットワーク上で送る必要をなくし、コンディションプッシュダウンを使える状態にあるが使用してないケースに比べて、クエリーの速度を 5 - 10 倍に増やします。詳細は 項4.2.7. 「コンディションプッシュダウン最適化」 をご覧ください。