実行計画の処理


MySQLのリファレンス: http://dev.mysql.com/doc/refman/5.6/en/explain-output.html

インデックスとテーブルへのアクセス

MySQLの実行計画は、使用されるインデックスの情報を多く表示するため、 間違った安心感を与える傾向があります。技術的には間違っていなくても、 効率的にインデックスが使われているという意味とは限りません。 最も重要なのはMySQLのexplainの出力にある TYPE列ですが、ここにINDEXと言うキーワードが 表示されていても、正しくインデックスが使われているとは限りません。

eq_ref, const

(INDEX UNIQUE SCANのように)1行のみを 見つけるためにBツリーの走査を行い、必要なら追加でテーブルから列を取り出します (TABLE ACCESS BY INDEX ROWID)。プライマリキーあるいは 一意制約により検索条件が2件以上にマッチしないことが確かな時に、データベースは この処理を行います。テーブルアクセスが発生するかどうかは「Using Index」も参照してください。

ref, range

Bツリーの走査を行い、一致するすべてのインデックスのエントリを探すのに リーフノードをたどり(INDEX RANGE SCANに似ています)、 必要ならテーブルストアから追加の列を取り出します(TABLE ACCESS BY INDEX ROWID)。テーブルアクセスが発生するかどうかは「Using Index」も参照してください。

index

インデックスの全体つまり全行を、インデックスの順番に 沿って読みます(INDEX FULL SCANと似ています)。

ALL

テーブル全体つまり全行・全列をディスクに保存されている通りに 読みます。IO処理も多いですが、フルテーブルスキャンでは 全てのテーブルの行の値をチェックしなければならないので、 かなりのCPU時間も消費します。「フルテーブルスキャン」も参照して下さい。

Using Index (「Extra」列)

「Extra」列に「Using Index」がある時は、 結果を返すのに必要な列が全てインデックスに含まれているため、 テーブルへのアクセスはありません。「using index ONLY」を思い出してみましょう。 ただし、クラスタインデックスを使用している場合(InnoDBでPRIMARYを 使用しているなど)は、技術的にはインデックスオンリースキャンと同じではありますが、 「Using Index」は表示されません。データのクラスタリング: インデックスの強力さの2つ目も参照してください。

PRIMARY (「key」または「possible_keys」列)

PRIMARYは、プライマリキーに自動的に作成される インデックスの名前です。

このウェブサイトにぴったりのカップは僕たちのショップにあります。
#見た目もいい感じだし、ここでの僕の仕事を支えてくれています

ソートとグルーピング

using filesort (「Extra」列)

Extra列に「using filesort」があるのは、実行される領域を問わず (メモリ上かディスク上か)明示的なソートが行われる時です。 「using filesort」は、中間結果(パイプライン化されていないもの)を マテリアライズするために非常に多くのメモリを必要とします。 「インデックスを使ったorder by」も参照してください。

最初のN件のみを選択するクエリ

暗黙のルール: 「Extra」列に「using filesort」がない事

MySQLの実行計画は、最初のN件のみを選択するクエリを明示的に表示しては くれません。limit句を使っており、 かつExtra列に「using filesort」がなければ、 パイプライン化されて実行されているという事になります。「最初のN行のみの選択」も参照してください。

Photo of Markus Winand
Markus Winand氏は、開発者がSQLパフォーマンスを改善するお手伝いをしています。 彼は、SQL Performance Explainedの 著者でもあり、出張トレーニングhttp://winand.at/での リモート講義も 行っています。