タイトル: 実行計画の出力
SEOタイトル: 実行計画の出力 完全ガイド（EXPLAIN / EXPLAIN ANALYZE / MySQL / PostgreSQL / Oracle / type / rows / 読み方とチューニング）
| この記事の要点 |
|
実行計画とは
SQL は宣言型の言語で、どのインデックスを使い、どんな順序で結合するかはオプティマイザが決めます。実行計画はその選択結果を可視化したものです。「インデックスが効いているか」「想定通りの結合順序か」「フルスキャンしていないか」を確認する基本ツールです。
MySQL の場合
-- 基本
EXPLAIN
SELECT * FROM users WHERE email = 'a@example.com';
-- JSON 形式（より詳細）
EXPLAIN FORMAT=JSON
SELECT * FROM users WHERE email = 'a@example.com';
-- 実測値つき（MySQL 8.0+ / 実際にクエリも走る）
EXPLAIN ANALYZE
SELECT u.name, COUNT(o.id)
FROM users u LEFT JOIN orders o ON o.user_id = u.id
GROUP BY u.id;MySQL の EXPLAIN で特に重要な列:
| 列 | 意味 | 注目ポイント |
|---|---|---|
type | アクセス方式 | ALL（全表走査）/ index / range / ref / eq_ref / const。左ほど遅い、右ほど速い |
key | 実際に使われたインデックス | NULL ならインデックス未使用 |
rows | 調べると推定される行数 | 大きいほど遅い。実テーブル全行 ≒ Full Scan |
Extra | 追加情報 | Using filesort（ソート発生）/ Using temporary（一時表）/ Using index（カバリング） |
PostgreSQL の場合
-- 計画のみ（クエリは実行しない）
EXPLAIN
SELECT * FROM users WHERE email = 'a@example.com';
-- 実際に走らせて実測値も出す（最重要）
EXPLAIN (ANALYZE, BUFFERS, VERBOSE)
SELECT u.name, COUNT(o.id)
FROM users u LEFT JOIN orders o ON o.user_id = u.id
WHERE u.created_at >= now() - interval '30 days'
GROUP BY u.id;PostgreSQL の代表的なノード:
| ノード | 意味 |
|---|---|
| Seq Scan | 全表走査。小さい表ならむしろ最適 |
| Index Scan | インデックス経由でテーブル参照 |
| Index Only Scan | インデックスだけで完結（高速） |
| Bitmap Heap/Index Scan | 中間規模ヒットで使われる |
| Hash Join / Merge Join / Nested Loop | 結合方式。データ量に応じてオプティマイザが選ぶ |
Oracle の場合
-- 計画を内部表に保存
EXPLAIN PLAN FOR
SELECT * FROM emp WHERE deptno = 10;
-- きれいに表示
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);
-- 直近実行した SQL の実プランを取る
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(NULL, NULL, 'ALLSTATS LAST'));Oracle の出力にはアクセスパス（TABLE ACCESS FULL / TABLE ACCESS BY INDEX ROWID / INDEX UNIQUE SCAN など）と Cost / Cardinality が並びます。Cost が極端に大きい行・Full Scan の行がチューニング対象です。
SQL Server の場合
-- 計画のみ（テキスト）
SET SHOWPLAN_TEXT ON;
GO
SELECT * FROM Users WHERE Email = 'a@example.com';
GO
SET SHOWPLAN_TEXT OFF;
-- 実行 + 実プラン（Management Studio では Ctrl+M）
SET STATISTICS PROFILE ON;
SELECT ...
SET STATISTICS PROFILE OFF;読み方の基本
- 下から上、内側から外側に読む（PostgreSQL / Oracle のツリー表示）
- 推定行数（rows / Cardinality）と実測の差が大きい行は統計情報が古いサイン
- type=ALL / Seq Scan / TABLE ACCESS FULL が大表で出ていたらインデックス追加候補
- Using filesort / Sort ノードが重ければ ORDER BY のキー / インデックスを再検討
- 結合順序が想定と違うときはヒント句や統計収集を検討
典型的な改善パターン
| 症状 | 対処 |
|---|---|
| WHERE のカラムでフルスキャン | そのカラムにインデックスを追加 |
関数 WHERE date(col)=... でインデックス無効 | 範囲条件に書き換え、もしくは関数インデックス |
| SELECT * で大きいカラムまで読む | 必要列のみに絞り、カバリングインデックスで完結 |
| 結合順序が悪い | 統計情報を最新化、駆動表を小さいほうに |
| 推定行数が実測と乖離 | MySQL: ANALYZE TABLE / Oracle: DBMS_STATS |
関連
- パフォーマンスチューニング — 親カテゴリ
- インデックス — B-Tree / 複合 / カバリング
- 統計情報 — オプティマイザの判断材料
- クエリオプティマイザ — 実行計画を決める仕組み