自己紹介

自分の写真

朝ネスのマスターやってる人。
巷では「けもネス」って呼ばれてるけど、「朝ネス」です。
どうか間違えないでください。

2015年3月3日火曜日

mysqlのEXPLAINの簡単な見方

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

それとサブクエリにもちゃんと個別でIndex効きます。
問題なのは基本1テーブルにつき、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なのでさらに早い。 最速。 ※結果は必ず1行か0行

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と同じじゃね?

結論:indexALLめっちゃ遅い

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


Extra
重要度:★★★★
何してるかを出す。 ここも見といたほうがいい。
Using where
いつでも見る。見ない方がおかしい。 whereを掛けないか。 もしくはtypeが「const」だったらでない。
Using temporary
一時テーブルのことである。。 これがあると若干遅くなるが、一時テーブルのレコード数が多いと一気に遅くなる、激遅。
Using filesort
クイックソートのことである。偶に出てくる。 これがあると若干遅くなるが、「Using temporary」と一緒にでてくると一気に遅くなる、激遅。 だいたいこんな感じ。

0 件のコメント:

コメントを投稿