MySQLのEXPLAINを使って、遅い原因と速い理由を探る
参考URL:
https://qiita.com/Nyokki/items/c2d95cb2a75d3c0acb64
https://nippondanji.blogspot.com/2009/03/mysqlexplain.html
EXPALIN SELECTのように通常のSQLの最初にEXPLAINと追加するだけで、実行計画を表示してくれる。
基本的には、8番目のrefカラムと、最後の11番目のExtraカラムを見て、SQLチューニングしていく
1番目のIDカラムは、ツリー階層を表している。
サブクエリがあるとid=2と表示される。
その中に、さらにサブクエリがあるとid=3と表示される
JOINは同じ階層で、ID=1のまま
2番目のselect_typeカラムは、クエリの種類を表す。
SIMPLEが単純なSELECT文
SUBQUERYが、そのままサブクエリ
PRIMARYが、サブクエリの親クエリ
3番目のtableカラムは、そのままテーブル名
4番目のTYPEカラムは、速度的にかなり重要(ALL,index,refをconstにするのがSQLチューニングの基本)
const = インデックス(primary, index, unique)が効いている。最速！
eq_ref = joinの結合キーにインデックスが、ちゃんと効いている。
ref = WHERE句でインデックス(primary, index, unique)が使われてない検索。
range = インデックスを用いた範囲検索。
index = インデックス全読み。ALLよりマシだけど普通遅い
ALL = 全検索、一番遅い
5番目のpossible_keysカラムは、クエリに適用できる可能性のあるインデックス（候補）
6番目のkeyカラムは、実際に選ばれて使われたインデックス（確定版）
7番目のkey_lenカラムは、keyカラムで使われているバイト数
8番目のrefカラムは、keyカラムをどうつかっているか？
const 定数値でインデックスを検索する。都道府県IDとか
NULL インデックスを使ってない
カラム名 他テーブルのカラムの値（JOINの結合キーとして使用）
9番目のrowsカラムは、統計情報から、だいたいの予測行数を表している
例えば、where id=123 が PRIMARY KEY なら 1 行だけ読むので rows = 1と表示される。
10番目のfilteredカラムは、where句で何パーセントくらいを表している
rows = インデックスありカラムのWHEREやJOIN条件を使って絞り込み(推測レコード数)
filtered = インデックス無しカラムのwhereを使って絞り込み(残るパーセント表示)
最後の11番目のExtraカラムは、mysqlのオプティマイザが何を行っているかを示す。
Using index = テーブルのデータ本体を読まず、インデックスだけで結果を取得できる。最速！
Using where = ほとんどのクエリで普通に出る。単純にWHERE句
Using temporary = JOINの結果をソートしたり、DISTINCTによる重複の排除を行う場合など、クエリの実行にテンポラリテーブルが必要なことを示す。遅い原因
Using filesort = インデックスを使わずに結果をfilesort（クイックソート）している。遅い原因