id (JSON 名): select_id )

SELECT 識別子。 これはクエリー内の SELECT の連番です。 行がほかの行の和集合結果を参照する場合に、値は NULL になることがあります。 この場合、table カラムには、<unionM,N> などの値が表示され、行が M および N の id 値のある行の和集合を参照していることが示されます。

select_type (JSON 名): none)

SELECT の種類で、次の表に示すもののいずれかになります。 JSON 形式の EXPLAIN は、SIMPLE または PRIMARY でないかぎり、SELECT タイプを query_block のプロパティとして公開します。 JSON 名 (該当する場合) もテーブルに示されます。

DEPENDENT は一般に、相関サブクエリーの使用を示します。 セクション13.2.11.7「相関サブクエリー」を参照してください。

DEPENDENT SUBQUERY の評価は UNCACHEABLE SUBQUERY の評価とは異なります。 DEPENDENT SUBQUERY の場合、その外部コンテキストの変数の異なる値の各セットにつき、一回だけサブクエリーが再評価されます。 UNCACHEABLE SUBQUERY の場合、外部コンテキストの行ごとにサブクエリーが再評価されます。

EXPLAIN で FORMAT=JSON を指定した場合、出力には select_type と直接同等の単一のプロパティはありません。query_block プロパティは特定の SELECT に対応します。 表示されているほとんどの SELECT サブクエリータイプに相当するプロパティが使用可能で (たとえば、materialized_from_subquery for MATERIALIZED)、必要に応じて表示されます。 SIMPLE または PRIMARY に相当する JSON はありません。

SELECT 以外のステートメントの select_type 値には、影響を受けるテーブルのステートメントタイプが表示されます。 たとえば、select_type は DELETE ステートメント用の DELETE です。

table (JSON 名): table_name )

出力の行で参照しているテーブルの名前。 これも次のいずれかの値になることがあります。

partitions (JSON 名): partitions )

クエリーでレコードが照合されるパーティション。 パーティション化されていないテーブルの場合、この値は NULL です。 セクション24.3.5「パーティションに関する情報を取得する」を参照してください。

type (JSON 名): access_type )

結合型。 さまざまな型の説明については、「EXPLAIN 結合型」を参照してください。

possible_keys (JSON 名): possible_keys )

possible_keys カラムは、MySQL がこのテーブルの行を検索するために選択できるインデックスを示します。 このカラムは EXPLAIN の出力に表示されたテーブルの順序にまったく依存しません。 つまり、possible_keys のキーの一部は、生成されたテーブルの順序で実際に使用できないことがあります。

このカラムが NULL の場合 (または JSON 形式の出力で未定義の場合)、関連するインデックスはありません。 この場合、WHERE 句を調査して、それがインデックス設定に適したカラムを参照しているかどうかをチェックすることで、クエリーのパフォーマンスを向上できることがあります。 その場合は、適切なインデックスを作成し、再度 EXPLAIN でクエリーをチェックします。 セクション13.1.9「ALTER TABLE ステートメント」を参照してください。

テーブルにあるインデックスを確認するには、SHOW INDEX FROM tbl_name を使用します。

key (JSON 名): key )

key カラムは、MySQL が実際に使用することを決定したキー (インデックス) を示します。 MySQL が行をルックアップするために、いずれかの possible_keys インデックスを使用することを決定した場合、キー値としてそのインデックスが一覧表示されます。

key は、possible_keys 値に存在しないインデックスに名前を付けることができます。 これは possible_keys インデックスのどれも行のルックアップに適していない場合に発生する可能性がありますが、クエリーによって選択されるすべてのカラムはほかのインデックスのカラムになります。 つまり、指定されたインデックスは選択されたカラムをカバーするため、取得する行を決定するために使用されませんが、インデックススキャンはデータ行スキャンよりも効率的です。

InnoDB は各セカンダリインデックスとともに主キー値を保存するため、InnoDB では、クエリーで主キーも選択している場合でも、セカンダリインデックスで選択されたカラムをカバーしている可能性があります。 key が NULL の場合、MySQL はクエリーをより効率的に実行するために使用するインデックスを見つけられませんでした。

MySQL で possible_keys カラムに示されたインデックスを強制的に使用させるか、無視させるには、クエリーで FORCE INDEX、USE INDEX、または IGNORE INDEX を使用します。 セクション8.9.4「インデックスヒント」を参照してください。

MyISAM テーブルの場合、ANALYZE TABLE を実行すると、オプティマイザがより適切なインデックスを選択するのに役立ちます。 MyISAM テーブルの場合、myisamchk --analyze も同様に動作します。 セクション13.7.3.1「ANALYZE TABLE ステートメント」およびセクション7.6「MyISAM テーブルの保守とクラッシュリカバリ」を参照してください。

key_len (JSON 名): key_length )

key_len カラムは、MySQL が使用することを決定したキーの長さを示します。 key_len の値を使用すると、MySQL が実際に使用するマルチパーティキーの部分の数を決定できます。 key カラムに NULL と表示されている場合、key_len カラムにも NULL と表示されます。

キーの格納形式のため、キーの長さは、NULL にできるカラムの長さが NOT NULL カラムの長さより大きくなります。

ref (JSON 名): ref )

ref カラムは、テーブルから行を選択するために、key カラムに指定されたインデックスに対して比較されるカラムまたは定数を示します。

値が func の場合、使用される値は、特定の関数の結果です。 どの関数を表示するには、EXPLAIN の後の SHOW WARNINGS を使用して、拡張 EXPLAIN 出力を表示します。 関数は、実際には算術演算子などの演算子である場合があります。

rows (JSON 名): rows )

rows カラムは、MySQL がクエリーを実行するために調査する必要があると考える行数を示します。

InnoDB テーブルの場合、これは推定値であり、常に正確ではないことがあります。

filtered (JSON 名): filtered )

filtered カラムは、テーブル条件でフィルタされるテーブルの行の推定割合を示します。 最大値は 100 で、これは行のフィルタリングが行われなかったことを意味します。 100 から減少する値は、フィルタリングの量が増加していることを示します。rows には調査された推定行数が表示され、rows×filtered には次のテーブルと結合された行数が表示されます。 たとえば、rows が 1000 で filtered が 50.00 (50%) の場合、次のテーブルと結合される行数は 1000×50% = 500 になります。

Extra (JSON 名): none)

このカラムには、MySQL がクエリーを解決する方法に関する追加情報が含まれます。 さまざまな値の説明については、「EXPLAIN の追加情報」を参照してください。

Extra カラムに対応する単一の JSON プロパティはありませんが、このカラムで発生する可能性のある値は JSON プロパティまたは message プロパティのテキストとして公開されます。

system

テーブルには行が 1 つしかありません (= system テーブル)。 これは、const 結合型の特殊なケースです。

const

テーブルには、一致するレコードが最大で 1 つあり、クエリーの開始時に読み取られます。 行が 1 つしかないため、この行のカラムの値は、オプティマイザの残りによって定数とみなされることがあります。const テーブルは、1 回しか読み取られないため、非常に高速です。

const は PRIMARY KEY または UNIQUE インデックスのすべてのパートを定数値と比較する場合に使用されます。 次のクエリーでは、tbl_name は const テーブルとして使用できます。

SELECT * FROM tbl_name WHERE primary_key=1;

SELECT * FROM tbl_name
  WHERE primary_key_part1=1 AND primary_key_part2=2;

eq_ref

前のテーブルの行の組み合わせごとに、このテーブルから 1 行ずつ読み取られます。 system と const 型以外で、これは最適な結合型です。 これは、結合でインデックスのすべてのパートが使用されており、インデックスが PRIMARY KEY または UNIQUE NOT NULL インデックスである場合に使用されます。

eq_ref は、= 演算子を使用して比較されるインデックス設定されたカラムに使用できます。 比較値は、定数またはこのテーブルより前に読み取られたテーブルのカラムを使用する式を指定できます。 次の例では、MySQL は eq_ref 結合を使用して、ref_table を処理できます。

SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column=other_table.column;

SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column_part1=other_table.column
  AND ref_table.key_column_part2=1;

ref

前のテーブルの行の組み合わせごとに、一致するインデックス値を持つすべての行がこのテーブルから読み取られます。ref は、結合でキーの左端のプリフィクスのみが使用される場合、またはキーが PRIMARY KEY や UNIQUE インデックスではない場合 (つまり、結合で、キー値に基づいて単一の行を選択できない場合) に使用されます。 使用されているキーがほんの数行にしか一致しない場合、これは適切な結合型です。

ref は、= または <=> 演算子を使用して比較されるインデックス設定されたカラムに使用できます。 次の例では、MySQL は ref 結合を使用して、ref_table を処理できます。

SELECT * FROM ref_table WHERE key_column=expr;

SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column=other_table.column;

SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column_part1=other_table.column
  AND ref_table.key_column_part2=1;

fulltext

結合は FULLTEXT インデックスを使用して実行されます。

ref_or_null

この結合型は、ref と似ていますが、MySQL が NULL 値を含む行の追加検索を実行することが追加されます。 この結合型の最適化は、ほとんどの場合に、サブクエリーの解決で使用されます。 次の例では、MySQL は ref_or_null 結合を使用して、ref_table を処理できます。

SELECT * FROM ref_table
  WHERE key_column=expr OR key_column IS NULL;

セクション8.2.1.15「IS NULL の最適化」を参照してください。

index_merge

この結合型はインデックスマージ最適化が使用されたことを示します。 この場合、出力行の key カラムには使用されたインデックスのリストが含まれ、key_len には使用されたインデックスの最長キーパートのリストが含まれます。 詳細については、セクション8.2.1.3「インデックスマージの最適化」を参照してください。

unique_subquery

このタイプは、次の形式の一部の IN サブクエリーで eq_ref に置き換わります:

value IN (SELECT primary_key FROM single_table WHERE some_expr)

unique_subquery は、効率化のため、サブクエリーを完全に置き換える単なるインデックスルックアップ関数です。

index_subquery

この結合型は unique_subquery に似ています。 IN サブクエリーを置き換えますが、次の形式のサブクエリー内の一意でないインデックスに対して機能します。

value IN (SELECT key_column FROM single_table WHERE some_expr)

range

行を選択するためのインデックスを使用して、特定の範囲にある行のみが取得されます。 出力行の key カラムは、使用されるインデックスを示します。 key_len には使用された最長のインデックスパートが格納されます。 この型の ref カラムは NULL です。

range は、=, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, LIKE または IN() 演算子のいずれかを使用してキーカラムを定数と比較する場合に使用できます:

SELECT * FROM tbl_name
  WHERE key_column = 10;

SELECT * FROM tbl_name
  WHERE key_column BETWEEN 10 and 20;

SELECT * FROM tbl_name
  WHERE key_column IN (10,20,30);

SELECT * FROM tbl_name
  WHERE key_part1 = 10 AND key_part2 IN (10,20,30);

インデックス

index 結合型は、インデックスツリーがスキャンされることを除いて、ALL と同じです。 これは 2 つの方法で行われます。

MySQL は、クエリーで単一のインデックスの一部であるカラムのみが使用されている場合に、この結合型を使用できます。

ALL

フルテーブルスキャンは、前のテーブルの行の組み合わせごとに実行されます。 これは、通常テーブルが const とマークされていない最初のテーブルである場合には適しておらず、通常ほかのすべてのケースで著しく不適切です。 通常、定数値または以前のテーブルからのカラム値に基づいて、テーブルからの行の取得を可能にするインデックスを追加することで、ALL を回避できます。

Child of 'table' pushed join@1 (JSON: message テキスト)

このテーブルは、NDB カーネルにプッシュダウンできる結合内の table の子として参照されます。 プッシュダウン結合が有効になっている場合、NDB Cluster でのみ適用されます。 詳細と例については、ndb_join_pushdown サーバーシステム変数の説明を参照してください。

const row not found (JSON プロパティ): const_row_not_found )

SELECT ... FROM tbl_name などのクエリーの場合、テーブルは空でした。

Deleting all rows (JSON プロパティ): message )

DELETE に対し、一部のストレージエンジン (MyISAM など) は簡単で高速にすべての行テーブルを削除するハンドラメソッドをサポートしています。 この Extra 値は、エンジンでこの最適化が使用された場合に表示されます。

Distinct (JSON プロパティ): distinct )

MySQL は個別の値を検索するため、最初に一致する行が見つかったら、現在の行の組み合わせについてのそれ以上の行の検索を停止します。

FirstMatch(tbl_name) (JSON プロパティ): first_match )

準結合 FirstMatch 結合ショートカット戦略は、tbl_name に使用されます。

Full scan on NULL key (JSON プロパティ): message )

これは、オプティマイザがインデックスルックアップアクセスメソッドを使用できない場合の代替の戦略として、サブクエリーの最適化で行われます。

Impossible HAVING (JSON プロパティ): message )

HAVING 句は常に false で、どの行も選択できません。

Impossible WHERE (JSON プロパティ): message )

WHERE 句は常に false で、どの行も選択できません。

Impossible WHERE noticed after reading const tables (JSON プロパティ): message )

MySQL はすべての const (および system) テーブルを読み取り、WHERE 句が常に false であることを通知します。

LooseScan(m..n) (JSON プロパティ): message )

準結合 LooseScan 戦略が使用されます。m および n は主要な部品番号です。

No matching min/max row (JSON プロパティ): message )

SELECT MIN(...) FROM ... WHERE condition などのクエリーの条件を満たす行がありません。

no matching row in const table (JSON プロパティ): message )

結合のあるクエリーで、空のテーブルまたは一意のインデックス条件を満足する行がないテーブルがありました。

No matching rows after partition pruning (JSON プロパティ): message )

DELETE または UPDATE に対し、オプティマイザはパーティションのプルーニング後に削除または更新するものが何も見つかりませんでした。 それは、SELECT ステートメントの Impossible WHERE に意味が似ています。

No tables used (JSON プロパティ): message )

クエリーに FROM 句がないか、FROM DUAL 句があります。

INSERT または REPLACE ステートメントで、SELECT パートがない場合に、EXPLAIN にこの値が表示されます。 たとえば、EXPLAIN INSERT INTO t VALUES(10) に対して、それは EXPLAIN INSERT INTO t SELECT 10 FROM DUAL と同等であるために表示されます。

Not exists (JSON プロパティ): message )

MySQL はクエリーに対する LEFT JOIN 最適化を実行でき、LEFT JOIN 条件に一致する 1 つの行が見つかったら、前の行の組み合わせについて、このテーブルでそれ以上の行を調査しません。 これは、このように最適化できるクエリーの種類の例です。

SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id
  WHERE t2.id IS NULL;

t2.id が NOT NULL で定義されているとします。 この場合、MySQL は t1 をスキャンし、t1.id の値を使用して t2 内の行をルックアップします。 MySQL が t2 内に一致する行を見つけた場合、t2.id は NULL にならないことがわかっているため、同じ id 値を持つ t2 内の残りの行をスキャンしません。 つまり、t1 の各行について、MySQL は、t2 内の実際に一致する行数にかかわらず、t2 内の単一のルックアップのみを実行する必要があります。

MySQL 8.0.17 以降では、NOT IN (subquery) または NOT EXISTS (subquery) 形式の WHERE 条件が内部的にアンチ結合に変換されたことを示すこともできます。 これにより、サブクエリーが削除され、そのテーブルが最上位のクエリーの計画に追加され、コスト計画が改善されます。 準結合とアンチ結合をマージすることで、オプティマイザは実行計画内のテーブルの順序をより自由に変更できるため、計画が高速になる場合があります。

特定のクエリーに対してアンチ結合変換が実行されるタイミングを確認するには、EXPLAIN の実行後に SHOW WARNINGS から Message カラムを確認するか、EXPLAIN FORMAT=TREE の出力で確認します。

Plan isn't ready yet (JSON プロパティ): none)

この値は、オプティマイザが名前付き接続で実行中のステートメントの実行計画の作成を終了していない場合に、EXPLAIN FOR CONNECTION で発生します。 実行計画の出力が複数の行で構成されている場合、オプティマイザが完全な実行計画を決定する進行状況に応じて、そのいずれかまたはすべてがこの Extra 値を持つ可能性があります。

Range checked for each record (index map: N) (JSON プロパティ) : message )

MySQL は使用に適したインデックスを見つけられませんでしたが、前のテーブルからのカラム値がわかったあとに、いくつかのインデックスが使用できることがわかりました。 以前のテーブルの行の組み合わせごとに、MySQL は range または index_merge アクセスメソッドを使用して、行を取得できるかどうかをチェックします。 これは、非常に高速ではありませんが、インデックスがまったくない結合の実行より高速です。 前のテーブルのすべてのカラム値がわかっており、定数とみなされることを除き、適用基準は、セクション8.2.1.2「range の最適化」とセクション8.2.1.3「インデックスマージの最適化」で説明されているとおりです。

インデックスは、テーブルの SHOW INDEX に示される同じ順序で 1 から番号付けされます。 インデックスマップ値 N は、候補となるインデックスを示すビットマスク値です。 たとえば、0x19 (バイナリ 11001) の値は、インデックス 1、4、および 5 が考慮されることを意味します。

Recursive (JSON プロパティ): recursive )

これは、行が再帰的共通テーブル式の再帰的 SELECT 部分に適用されることを示します。 セクション13.2.15「WITH (共通テーブル式)」を参照してください。

Rematerialize (JSON プロパティ): rematerialize )

Rematerialize (X,...) は、T テーブルの EXPLAIN 行に表示されます。X は、T の新しい行が読み取られたときに再実体化がトリガーされるラテラル導出テーブルです。 例:

SELECT
  ...
FROM
  t,
  LATERAL (derived table that refers to t) AS dt
...

導出テーブルの内容は、上位クエリーによって t の新しい行が処理されるたびに最新になるように再実体化されます。

Scanned N databases (JSON プロパティ): message )

これは、セクション8.2.3「INFORMATION_SCHEMA クエリーの最適化」に説明するように、サーバーが INFORMATION_SCHEMA テーブルのクエリーを処理する際に実行するディレクトリスキャンの数を示します。 N の値は 0、1、または all です。

Select tables optimized away (JSON プロパティ): message )

オプティマイザは、1) 最大 1 つの行を戻す必要があると判断しました。2) この行を生成するには、確定的な行セットを読み取る必要があります。 読取り対象の行を最適化フェーズ中 (インデックス行の読取りなど) に読み取ることができる場合、クエリーの実行中にテーブルを読み取る必要はありません。

最初の条件は、クエリーが暗黙的にグループ化されるときに満たされます (集計関数は含まれますが、GROUP BY 句は含まれません)。 2 番目の条件は、使用されるインデックスごとに 1 つの行検索が実行されるときに満たされます。 読み取られるインデックスの数によって、読み取る行数が決まります。

暗黙的にグループ化された次のクエリーについて考えてみます:

SELECT MIN(c1), MIN(c2) FROM t1;

あるインデックス行を読み取ることで MIN(c1) を取得でき、別のインデックスからある行を読み取ることで MIN(c2) を取得できるとします。 つまり、カラム c1 および c2 ごとに、カラムがインデックスの最初のカラムであるインデックスが存在します。 この場合、2 つの決定的な行を読み取ることによって生成された 1 つの行が返されます。

読み取る行が決定的でない場合、この Extra 値は発生しません。 次のクエリーについて考えてみます:

SELECT MIN(c2) FROM t1 WHERE c1 <= 10;

(c1, c2) がカバーインデックスであるとします。 このインデックスを使用して、c1 <= 10 のすべての行をスキャンし、c2 の最小値を検索する必要があります。 対照的に、次のクエリーについて考えてみます:

SELECT MIN(c2) FROM t1 WHERE c1 = 10;

この場合、c1 = 10 の最初のインデックス行には、c2 の最小値が含まれます。 返される行を生成するには、1 つの行のみを読み取る必要があります。

テーブルごとに正確な行数を保持するストレージエンジン (MyISAM など、InnoDB は保持しない) の場合、WHERE 句が欠落しているか常に true で、GROUP BY 句がない COUNT(*) クエリーに対してこの Extra 値が発生することがあります。 (これは暗黙的にグループ化されたクエリーのインスタンスであり、ストレージエンジンは確定的な行数を読み取ることができるかどうかに影響します。)

Skip_open_table, Open_frm_only, Open_full_table (JSON プロパティ): message )

これらの値は、INFORMATION_SCHEMA テーブルのクエリーに適用されるファイルオープンの最適化を示します。

Start temporary、End temporary (JSON プロパティ): message )

これは、準結合重複除去ストラテジの一時テーブルの使用を示します。

unique row not found (JSON プロパティ): message )

SELECT ... FROM tbl_name などのクエリーの場合に、テーブルに UNIQUE インデックスまたは PRIMARY KEY の条件を満たす行がありません。

Using filesort (JSON プロパティ): using_filesort )

MySQL はソート順で行を取得する方法を見つけるために、追加のパスを実行する必要があります。 ソートは、結合型に従ってすべての行を進み、ソートキーと WHERE 句に一致するすべての行について行へのポインタを格納して実行されます。 次にキーがソートされ、ソート順で行が取得されます。 セクション8.2.1.16「ORDER BY の最適化」を参照してください。

Using index (JSON プロパティ): using_index )

実際の行を読み取るための追加のシークを実行する必要がなく、インデックスツリーの情報のみを使用して、テーブルからカラム情報が取得されます。 この戦略は、クエリーで単一のインデックスの一部であるカラムのみを使用している場合に使用できます。

ユーザー定義のクラスタ化されたインデックスを持つ InnoDB テーブルの場合、そのインデックスは Extra カラムに Using index がない場合でも使用できます。 これは、type が index で key が PRIMARY の場合です。

Using index condition (JSON プロパティ): using_index_condition )

インデックスタプルにアクセスし、まずそれらをテストして、すべてのテーブル行を読み取るかどうかを判断することによって、テーブルが読み取られます。 このように、必要でないかぎり、すべてのテーブル行の読み取りを遅延 (「プッシュダウン」) するためにインデックス情報が使用されます。 セクション8.2.1.6「インデックスコンディションプッシュダウンの最適化」を参照してください。

Using index for group-by (JSON プロパティ): using_index_for_group_by )

Using index テーブルアクセスメソッドと同様に、Using index for group-by は MySQL が、実際のテーブルへの追加のディスクアクセスをせずに、GROUP BY または DISTINCT クエリーのすべてのカラムを取得するために使用できるインデックスを見つけたことを示します。 さらに、各グループに対して、少数のインデックスエントリだけが読み取られるように、インデックスがもっとも効率的に使われます。 詳細は、セクション8.2.1.17「GROUP BY の最適化」を参照してください。

Using index for skip scan (JSON プロパティ): using_index_for_skip_scan )

スキップスキャンアクセスメソッドが使用されていることを示します。 スキャン範囲アクセス方法のスキップを参照してください。

Using join buffer (Block Nested Loop), Using join buffer (Batched Key Access), Using join buffer (hash join) (JSON プロパティ): using_join_buffer )

初期の結合からのテーブルは、部分ごとに結合バッファーに読み込まれ、それらの行がバッファーから使用されて、現在のテーブルとの結合が実行されます。 (Block Nested Loop) ではブロックネスト - ループアルゴリズムが使用され、(Batched Key Access) ではバッチキーアクセスアルゴリズムが使用され、(hash join) ではハッシュ結合が使用されます。 つまり、EXPLAIN 出力の前の行にあるテーブルのキーがバッファされ、Using join buffer が表示される行で表されるテーブルから一致する行がバッチでフェッチされます。

JSON 形式の出力では、using_join_buffer の値は常に Block Nested Loop、Batched Key Access または hash join のいずれかです。

ハッシュ結合は、MySQL 8.0.18 以降で使用できます。Block Nested-Loop アルゴリズムは、MySQL 8.0.20 以降の MySQL リリースでは使用されません。 これらの最適化の詳細は、セクション8.2.1.4「ハッシュ結合の最適化」 および Block Nested Loop 結合アルゴリズム を参照してください。

バッチキーアクセスアルゴリズムの詳細は、Batched Key Access 結合 を参照してください。

Using MRR (JSON プロパティ): message )

テーブルは Multi-Range Read 最適化戦略を使用して読み取られます。 セクション8.2.1.11「Multi-Range Read の最適化」を参照してください。

Using sort_union(...), Using union(...), Using intersect(...) (JSON プロパティ): message )

これらは、index_merge 結合タイプのインデックススキャンのマージ方法を示す特定のアルゴリズムを示します。 セクション8.2.1.3「インデックスマージの最適化」を参照してください。

Using temporary (JSON プロパティ): using_temporary_table )

クエリーを解決するために、MySQL は結果を保持する一時テーブルを作成する必要があります。 これは一般に、クエリーに、カラムを異なって一覧表示する GROUP BY 句と ORDER BY 句が含まれる場合に発生します。

Using where (JSON プロパティ): attached_condition )

WHERE 句は、次のテーブルに対して照合されるか、またはクライアントに送信される行を制限するために使用されます。 具体的にテーブルからすべての行をフェッチするか、調査する意図がないかぎり、Extra 値が Using where でなく、テーブル結合型が ALL または index である場合、クエリーに何らかの誤りがある可能性があります。

JSON 形式の出力では、Using where に直接対応するものはありません。attached_condition プロパティには、使用される WHERE 条件が含まれます。

Using where with pushed condition (JSON プロパティ): message )

この項目は NDB テーブルのみに適用されます。 つまり、NDB Cluster は条件プッシュダウン最適化を使用して、インデックスなしカラムと定数の間の直接比較の効率を向上させています。 そのような場合、条件がクラスタのデータノードに「プッシュダウン」され、すべてのデータノードで同時に評価されます。 これにより、一致しない行をネットワーク経由で送る必要がなくなり、コンディションプッシュダウンを使用できるが使用しない場合より、そのようなクエリーを 5 - 10 倍高速化できます。 詳細は、セクション8.2.1.5「エンジンコンディションプッシュダウンの最適化」を参照してください。

Zero limit (JSON プロパティ): message )

クエリーに LIMIT 0 句があり、行を選択できません。

比較対象のカラムは次のように宣言されています。

テーブルには次のインデックスがあります。

tt.ActualPC 値は均一に分布されていません。