mysql explain詳細
2410 ワード
遅いクエリ最適化の過程でexplainを理解する上で重要な一環
次のsqlを例に挙げます.
id
select_type
table
type
possible_keys
key
key_len
ref
rows
Extra
1
SIMPLE
clients
Index
Null
index_xxx
1
Null
29971
Using Index
各情報の意味id:SELECTクエリの識別子.SELECTごとに一意の識別子が自動的に割り当てられます. select_type:SELECT検索のタイプ. table:どのテーブルをクエリーしているのか type:アクセスタイプ possible_keys:今回のクエリで選択可能なインデックス key:今回のクエリで確実に使用するインデックス. ref:どのフィールドまたは定数がkeyとともに使用されるか rows:このクエリの合計スキャン数を示す.これは推定値です. extra:追加情報 typeには以下のタイプがある場合があります(効率が高いから低いまで)system(効率的)const接続タイプの特例であり、表は1行のみ条件を満たす. const(効率的)最大1行しか一致しないと判断した場合、MySQLオプティマイザはクエリの前に1回だけ読み込んでしまうため、非常に高速です.プライマリ・キーがwhere句に挿入されると、mysqlはこのクエリを定数に変換します eq_ref(効率的)は、最大1つの条件を満たすレコードのみを返します.一意性インデックスまたはプライマリ・キーを使用して検索すると発生します refは、1つの値に一致するすべてのローを返すインデックス・アクセスです.このようなインデックス・アクセスは、非一意性インデックスまたは一意性インデックスの非一意性接頭辞を使用する場合にのみ発生します.このタイプはeq_とrefとは異なり、関連付け操作でインデックスの最左接頭辞のみが使用されるか、インデックスがUNIQUEおよびPRIMARY KEYではない.refは、=または<=>オペレータのインデックス付きカラムを使用することができます. rangeレンジスキャン、制限付きインデックススキャン.key列には、どのインデックスが使用されているかが表示されます.=、<>、>、>=、、BETWEENまたはINオペレータを使用してキーワード列を定数で比較する場合は、range indexは全テーブルスキャンと同じです.ローではなくインデックス順にテーブルをスキャンするだけです.主な利点は、ソートを回避することですが、オーバーヘッドは依然として非常に大きいことです.Extra列でUsing indexを見た場合、上書きインデックスを使用していることを示し、インデックスのデータのみをスキャンしているが、インデックス順の全テーブルスキャンよりもコストがかなり小さい Nullはmysqlが最適化段階でクエリ文を分解できることを意味し、実行段階ではテーブルやインデックスへのアクセスもできない(効率的) Q:なぜ
primary keyはclustered indexの体積が比較的大きく,肯定走査がより小さいインデックス効率が最も高い.
次のsqlを例に挙げます.
explain select count(*) from clients;
id
select_type
table
type
possible_keys
key
key_len
ref
rows
Extra
1
SIMPLE
clients
Index
Null
index_xxx
1
Null
29971
Using Index
各情報の意味
explain select * from orders where id = x;
explain select * from orders where uniq_key_col = x;
explain select * from orders where common_key_col = x;
explain select * from orders where id in (1,2);
explain select id from clients;
select count(*) from clients;
このクエリはprimary key Aを選択していないのかexplain
この文はインデックススキャンであることがわかります.具体的にそのインデックスを選択した場合、主にそのインデックスの体積が小さいことを見ますexplain select count(*) from clients;
primary keyはclustered indexの体積が比較的大きく,肯定走査がより小さいインデックス効率が最も高い.
show index from clients;
select count(*)
最適化できないクエリで頻繁な操作が必要な場合はcount cache
より良い選択かも