ドキュメント
Computer Science
データベース
SQL クエリと操作
Explain

Explain

データベース EXPLAIN 指令しれい結果けっか値ちの詳細しょうさいな解説かいせつ。

MySQL EXPLAIN

select_type の詳細

種類しゅるい説明せつめい
SIMPLE単純たんじゅんなクエリ、サブクエリや UNION を含ふくまない
PRIMARY最もっとも外側そとがわの SELECT クエリ
UNIONUNION の2番目ばんめ以降いこうの SELECT
DEPENDENT UNION外部がいぶクエリに依存いぞんする UNION の SELECT
UNION RESULTUNION クエリの結果けっかセット（一時いちじテーブル）
SUBQUERYSELECT 句く、WHERE、HAVING 句くの最初さいしょのサブクエリ
DEPENDENT SUBQUERY外部がいぶクエリに依存いぞんするサブクエリ
DERIVED派生はせいテーブル（FROM 句くのサブクエリ）
MATERIALIZEDマテリアライズドサブクエリ、MySQL 5.6+ の最適化さいてきか
UNCACHEABLE SUBQUERYキャッシュ不可ふかのサブクエリ
UNCACHEABLE UNIONキャッシュ不可ふかの UNION

type の詳細（効率の高い順）

種類しゅるい説明せつめい
systemテーブルに1行ぎょうのみ（const の特例とくれい）
const主しゅキーまたはユニークインデックスの等値とうちクエリ、最大さいだい1行ぎょう
eq_ref主しゅキーまたはユニーク非NULL インデックスの結合けつごうクエリ
ref非ユニークインデックススキャン
fulltext全文ぜんぶんインデックスを使用しよう
ref_or_nullref と同様どうようだが NULL 値ちも検索けんさく
index_mergeインデックスマージ最適化さいてきか、複数ふくすうインデックスを使用しよう
unique_subqueryIN サブクエリの最適化さいてきか
index_subqueryunique_subquery と同様どうようだが非ユニークインデックス
range指定してい範囲はんいのみスキャン
index全ぜんインデックススキャン
ALL全ぜんテーブルスキャン、効率こうりつ最低さいてい

Extra フィールドの詳細

値あたい説明せつめい
Using indexカバリングインデックス、インデックスのみ使用しよう
Using whereWHERE 句くでフィルタリング
Using temporary一時いちじテーブルを作成さくせい
Using filesort外部がいぶソートを使用しよう、パフォーマンス問題もんだいの可能性かのうせい
Using join buffer結合けつごうバッファを使用しよう
Impossible WHEREWHERE 句くが常つねに false
Using index conditionインデックスコンディションプッシュダウン（ICP）
Using MRRマルチレンジリード最適化さいてきか

rows と filtered の解釈

rows：MySQL が検査けんさする必要ひつようがあると推定すいていする行数ぎょうすう。低ひくいほど良よい。

filtered：条件じょうけんでフィルタリング後ごに残のこる行ぎょうの割合わりあい（%）。実際じっさいに検査けんさする行ぎょう：rows × filtered%。

PostgreSQL EXPLAIN

ノードタイプの詳細

種類しゅるい説明せつめい
Seq Scanシーケンシャルスキャン、テーブル全体ぜんたいを読よむ
Index Scanインデックススキャン、インデックス後ごにテーブルアクセス
Index Only Scanインデックスオンリースキャン、最もっとも効率的こうりつてき
Bitmap Scanビットマップスキャン、一致いっち行ぎょうのビットマップを作成さくせい
Nested Loopネステッドループ結合けつごう
Hash Joinハッシュ結合けつごう
Merge Joinマージ結合けつごう、ソート済ずみデータを並行へいこうスキャン
Sortソート操作そうさ
Limit戻もどす行数ぎょうすうを制限せいげん
Aggregate集約しゅうやく関数かんすう操作そうさ

cost 値の意味

  • 単位：ディスクページ取得しゅとくを基準きじゅん
  • startup cost：最初さいしょの出力しゅつりょく行ぎょうを生成せいせいするまでのコスト
  • total cost：すべての出力しゅつりょく行ぎょうを生成せいせいする総そうコスト
cost=0.42..1.42 rows=10 width=14
  • 0.42：最初さいしょの行ぎょうを生成せいせいするコスト
  • 1.42：すべての10行ぎょうの総そうコスト
  • 各かく行ぎょうの平均へいきん幅はば 14 バイト

actual time（EXPLAIN ANALYZE 使用時） 

actual time=0.015..0.018 rows=10 loops=1
  • 0.015ms：最初さいしょの行ぎょうを取得しゅとくする時間じかん
  • 0.018ms：すべての行ぎょうを処理しょりする総そう時間じかん
  • loops：ノードの実行じっこう回数かいすう
  • 総そう実際じっさい時間じかん = actual time × loops

バッファ情報（EXPLAIN (ANALYZE, BUFFERS) 使用時）

指標しひょう説明せつめい
shared hit共有きょうゆうバッファから読よみ込こんだブロック数すう
shared readディスクから共有きょうゆうバッファに読よみ込こんだブロック数すう
shared dirtiedクエリによって変更へんこうされた共有きょうゆうバッファブロック数すう
shared written共有きょうゆうバッファからディスクに書かき込こんだブロック数すう
temp read/written一時いちじファイルの読よみ書かき

Filter と Index Cond の違い

  • Index Cond：インデックスで直接ちょくせつ一致いっち行ぎょうを検索けんさく、より効率的こうりつてき
  • Filter：行ぎょうを取得しゅとく後ごにフィルタリング

MongoDB EXPLAIN

verbosity モード

モード説明せつめい
queryPlannerデフォルト、クエリ計画けいかくのみ表示ひょうじ
executionStats実行じっこう統計とうけいを含ふくむ
allPlansExecutionすべての計画けいかくの統計とうけい、最もっとも詳細しょうさい

stage の詳細

Stage説明せつめいパフォーマンス
COLLSCANコレクションスキャン、すべてのドキュメントをスキャン❌ 最低さいてい
IXSCANインデックススキャン✅ 効率的こうりつてき
FETCHインデックスから情報じょうほう取得後しゅとくごドキュメントを読よむ中程度ちゅうていど
SORTメモリソート、インデックスが使つかえない場合ばあい⚠️ 問題もんだいの可能性かのうせい
LIMIT戻もどすドキュメント数すうを制限せいげん✅
SKIP指定してい数すうのドキュメントをスキップ⚠️ 大量たいりょう SKIP は問題もんだい
IDHACK_id フィールドの特別とくべつ最適化さいてきか✅ 効率的こうりつてき
COUNT_SCANインデックスでカウント✅
PROJECTION_COVEREDすべてのフィールドがインデックスに含ふくまれる✅ 最高さいこう

executionStats の主要指標

指標しひょう説明せつめい
nReturnedクライアントに返かえされたドキュメント数すう
executionTimeMillis実行じっこう時間じかん（ミリ秒びょう）
totalKeysExaminedスキャンしたインデックスキーの総数そうすう
totalDocsExaminedスキャンしたドキュメントの総数そうすう

クエリ効率の判断基準

最良さいりょうのケース：nReturned ≈ totalKeysExamined ≈ totalDocsExamined
  • インデックスカバリングクエリ：totalKeysExamined > 0 かつ totalDocsExamined = 0
  • インデックス効率こうりつ：totalKeysExamined / nReturned 比率ひりつは 1:1 に近ちかいべき
  • ドキュメントスキャン効率こうりつ：totalDocsExamined / nReturned 比率ひりつは 1:1 に近ちかいべき

危険信号

  • 大おおきなコレクションでの COLLSCAN
  • totalDocsExamined » nReturned（必要ひつよう以上いじょうのドキュメントをスキャン）
  • 高たかい executionTimeMillis だが低ひくい nReturned
  • SORT ステージで memUsage が memLimit に近ちかい

クエリ最適化の典型例

COLLSCAN の改善

問題: { stage: "COLLSCAN", totalDocsExamined: 10000, nReturned: 10 }
解決: クエリ条件に適したインデックスを作成

インデックス効率低下

問題: { stage: "IXSCAN", totalKeysExamined: 5000, nReturned: 10 }
解決: より精確な複合インデックスを作成

ソートがインデックスを使用しない

問題: { stage: "SORT", executionTimeMillis: 500, memUsage: 30000000 }
解決: ソートフィールドを含むインデックスを作成

SKIP の効率問題

問題: 大量の SKIP でページネーション
解決: 前回のクエリ結果に基づく条件（例：{ _id: { $gt: lastId } }）

関連トピック

SQL Glossary