mysqlのEXPLAINの簡単な見方

mysqlのEXPLAINの見方ってマジ意味わかんないので調べてまとめ。

それとサブクエリにもちゃんと個別でIndex効きます。
問題なのは基本１テーブルにつき、Indexが1つしか使わない仕様。
基本とかいうけど別にor検索なら今は自動で2つIndex使ってくれる。
昔は無理やり使うためにUnionAllしてたらしい。どうでもいいね。
あと複合Indexが地味に1つのIndexとして扱われえるのが分かりにくいというか、
分かりやすい情報が無くて辛い。いつか書く。需要は知らん。

---

possible_keys

重要度：★★★☆☆
テーブルにアクセスする際に使えるINDEXを出します。覚えておいて損はないでしょう。
※keyの候補ですね。「使える」というだけで、実際に使ったのは「key」カラムに乗ります。

key

重要度：★★★☆☆
テーブルにアクセスするのに使うINDEXを出します。どのINDEXを使ったのかが分かります。
※実際に使ったkeyですね。

type

重要度：★★★★★
テーブルに対してどういうアクセスをしているかを示す。ぶっちゃけこれ見れば大体OK。

早いの

const
「PRIMARY KEY」もしくは「UNIQUEINDEX」を使ったアクセス方法。 INDEXを使っているので早い。しかも一意性のあるINDEXなのでさらに早い。 最速。 ※結果は必ず１行か０行。

ref
「INDEX」を使ったアクセス方法。 INDEXを使っているので早い。一意性でないINDEXを使っているため「const」よりは遅いが早い。 超速い。 ※結果は0～n行。

range
「INDEX」を使ったアクセス方法。 INDEXが一意性だろうが無かろうが範囲検索すると出てくる。IN句等で必ず出てきます。 超速い。 ※結果は0～n行。

結論：refかrangeを狙おう。constは基本無理ゲー。

遅いの

index
フルインデックススキャン。 インデックス全体をスキャンする必要があるのでとても遅い。 かなり遅いんじゃないかな。 どんくらい遅いかは知らない。 →スゲー遅かった。200万行で1.3秒。

ALL
フルテーブルスキャン。インデックスがまったく利用されていないことを示す。 一番遅いんじゃないかな。 なんにせよ激遅。 レコードが1万以上あるテーブルにアクセスしてこれが出てきたら気を付けよう。 →論外。200万行で1.3秒。あれ？indexと同じじゃね？

結論：indexもALLもめっちゃ遅い。

その他

eq_ref
JOINの時に一意性のあるKEYを使うとでてくる。 速いかどうかは知らない。

Extra

重要度：★★★★☆
何してるかを出す。 ここも見といたほうがいい。

Using where

いつでも見る。見ない方がおかしい。 whereを掛けないか。 もしくはtypeが「const」だったらでない。

Using temporary

一時テーブルのことである。。 これがあると若干遅くなるが、一時テーブルのレコード数が多いと一気に遅くなる、激遅。

Using filesort

クイックソートのことである。偶に出てくる。 これがあると若干遅くなるが、「Using temporary」と一緒にでてくると一気に遅くなる、激遅。 だいたいこんな感じ。