システム

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は、インデックスの左端の先頭部分のみが結合で使用される場合、またはインデックスが UNIQUEや PRIMARY KEYではない場合（すなわち、この結合において、インデックス値から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;

ref_or_null

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

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

項6.2.7. 「IS NULL最適化」参照。

index_merge

この結合型はインデックス併合最適化が使用されたことを示しています。この場合、出力行のkeyカラムは使用されたインデックスのリストが含まれ、key_lenには使用されたインデックスの最長キー部分が含まれます。詳細は 項6.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 は現在のレコードの組み合わせによるその後のレコード検索を続行しないことを示す。

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のチェックが実行され、このインデックスがテーブルからのレコードの取り出しに使用される。非常に高速ではないが、インデックスなしの結合と比較すると高速である。 適用基準は項6.2.5. 「Range 最適化」と項6.2.6. 「インデックス結合最適化」で説明されています。ただし、これは前テーブルの全てのカラム値が知られており、定数であるという前提においてです。

Select tables optimized away

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

Using filesort

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

Using index

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

Using temporary

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

Using where

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

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

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

Using index for group-by

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

Using where with pushed condition

このアイテムはNDB Clusterテーブルにのみ適用されます。それはMySQL クラスタがcondition pushdownを使用して行う、インデックスのないカラムと定数を直接比較(=)の効率化を図ることを意味します。その場合、状態はクラスターのデータノードに「押し戻され」ており、全てのパーティションで同時に評価されます。これはマッチしない行をネットワーク上で送る必要を無くし、コンディションプッシュダウンが使える状態にあり、使用しないケースでそのようなクエリの速度を５乗から１０乗に増やす。

以下のように定義されたクラスタテーブルがあるとします。

CREATE TABLE t1 (
    a INT, 
    b INT, 
    KEY(a)
) ENGINE=NDBCLUSTER;

この場合、コンディションプッシュダウンは下記のようなクエリで使用できます。

SELECT a,b FROM t1 WHERE b = 10;

これはEXPLAIN SELECTの出力で見られます。例えば

mysql> EXPLAIN SELECT a,b FROM t1 WHERE b = 10\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t1
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 10
        Extra: Using where with pushed condition

コンディションプッシュダウンは下記の２つのクエリと一緒には使用できません。

SELECT a,b FROM t1 WHERE a = 10;
SELECT a,b FROM t1 WHERE b + 1 = 10;

この二つのクエリのうち最初のものに関しては、インデックスがaカラムに存在するため、コンディションプッシュダウンは適用できません。２番目のクエリの場合、インデックスのないカラムbに関する比較は直接的でないため、コンディションプッシュダウンが適用できません。(ただし、b + 1 = 10をWHERE 節内でb = 9に減らす場合は適用されます。)

ただし、>または<演算子を使用している定数とインデックスカラムが比較された場合、コンディションプッシュダウンが使用される場合もあります。

mysql> EXPLAIN SELECT a,b FROM t1 WHERE a<2\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: t1
         type: range
possible_keys: a
          key: a
      key_len: 5
          ref: NULL
         rows: 2
        Extra: Using where with pushed condition

コンディションプッシュダウンに関して、以下のことに留意してください。