MySQLクエリーアナライザEXPLAINまたはDESC
3117 ワード
MySQLでは、EXPLAINまたはDESCを使用してSQL文の実行状況を表示および分析できます.2006年のすべての企業の売上高を計算するには、salesテーブルとcompanyテーブルを関連付け、moneyフィールドを求めて操作する必要があります.対応するSQLは次のとおりです.
列の説明:
select_type:SELECTのタイプを表して、よくあるのは以下のいくつかがあります
SIMPLE:単純テーブル、接続やサブクエリを使用しない
PRIMARY:プライマリ・クエリー、すなわち外層クエリー
UNION:UNIONの2番目または後のクエリ文
SUBQUERY:サブクエリの最初のSELECT
table:結果セットを出力するテーブル
type:テーブルの接続タイプを表し、性能が良いから悪いまでの接続タイプは以下の順序である.
System:テーブルに1行しかない定数テーブル
const:primary keyやunique indexなど、単一テーブルに最大1つの一致行があります.
eq_ref:前の各ローについて、このテーブルでは1つのレコードのみがクエリーされます.つまり、primary keyまたはunique indexを使用するマルチテーブル接続です.
ref:とeq_refは、primary keyまたはunique indexではなく、通常のインデックスを使用する点で異なります.
ref_or_null:refタイプと異なり、条件にnullに対するクエリーが含まれている
index_merge:インデックスマージ最適化
unique_subquery:inの後ろには、クエリー・プライマリ・キー・フィールドのサブクエリーがあります.
index_subquery:unique_とsubqueryは、inの後にクエリが一意でないインデックスフィールドのサブクエリであることを区別します.
range:単一テーブルの範囲クエリー
index:前の各ローについて、インデックスをクエリーしてデータを取得します.
all:前の各ローについて、全テーブルをスキャンしてデータを取得します.
possible_keys:クエリーで使用可能なインデックス
key:クエリー時に実際に使用されるインデックス
key-len:インデックスフィールドの長さ
rows:スキャン行の数
Extra:実行状況の説明と説明
EXPLAINの解析により、上記の例ではsalesテーブルの全テーブルスキャンが効率的でないことを確認し、salesテーブルにインデックスを作成します.
インデックスを作成した後、クエリ文を次のように分析します.
EXPLAIN SELECT SUM(money) FROM sales s,company c WHERE s.company_id=c.id AND s.year=2006 \G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: s
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 1000
Extra: Using where
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: c
type: ref
possible_keys: index_company_id
key: index_company_id
key_len: 5
ref: sakila.c.company_id
rows: 1
Extra: Using where; Using index
列の説明:
select_type:SELECTのタイプを表して、よくあるのは以下のいくつかがあります
SIMPLE:単純テーブル、接続やサブクエリを使用しない
PRIMARY:プライマリ・クエリー、すなわち外層クエリー
UNION:UNIONの2番目または後のクエリ文
SUBQUERY:サブクエリの最初のSELECT
table:結果セットを出力するテーブル
type:テーブルの接続タイプを表し、性能が良いから悪いまでの接続タイプは以下の順序である.
System:テーブルに1行しかない定数テーブル
const:primary keyやunique indexなど、単一テーブルに最大1つの一致行があります.
eq_ref:前の各ローについて、このテーブルでは1つのレコードのみがクエリーされます.つまり、primary keyまたはunique indexを使用するマルチテーブル接続です.
ref:とeq_refは、primary keyまたはunique indexではなく、通常のインデックスを使用する点で異なります.
ref_or_null:refタイプと異なり、条件にnullに対するクエリーが含まれている
index_merge:インデックスマージ最適化
unique_subquery:inの後ろには、クエリー・プライマリ・キー・フィールドのサブクエリーがあります.
index_subquery:unique_とsubqueryは、inの後にクエリが一意でないインデックスフィールドのサブクエリであることを区別します.
range:単一テーブルの範囲クエリー
index:前の各ローについて、インデックスをクエリーしてデータを取得します.
all:前の各ローについて、全テーブルをスキャンしてデータを取得します.
possible_keys:クエリーで使用可能なインデックス
key:クエリー時に実際に使用されるインデックス
key-len:インデックスフィールドの長さ
rows:スキャン行の数
Extra:実行状況の説明と説明
EXPLAINの解析により、上記の例ではsalesテーブルの全テーブルスキャンが効率的でないことを確認し、salesテーブルにインデックスを作成します.
CREATE INDEX index_sales_year ON sales(year);
インデックスを作成した後、クエリ文を次のように分析します.
EXPLAIN SELECT SUM(money) FROM sales s,company c WHERE s.company_id=c.id AND s.year=2006 \G;
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: s
type: ref
possible_keys: index_seles_year
key: index_sales_year
key_len: 2
ref: const
rows: 1
Extra: Using where
*************************** 2. row ***************************
id: 1
select_type: SIMPLE
table: c
type: ref
possible_keys: index_company_id
key: index_company_id
key_len: 5
ref: sakila.c.company_id
rows: 1
Extra: Using where; Using index