この記事の要点

SQL の処理経路を可視化するのが実行計画。SELECT の前に EXPLAIN を付けて出力する MySQL: EXPLAIN SELECT ... / EXPLAIN FORMAT=JSON / EXPLAIN ANALYZE（実測値） PostgreSQL: EXPLAIN (ANALYZE, BUFFERS) ... で実際の実行時間と I/Oまで見える Oracle: EXPLAIN PLAN FOR ... → DBMS_XPLAN.DISPLAY で表示 チェックすべきは type / access 方式（ALL / index / range / ref / eq_ref / const）と rows（推定行数）。Full Scan を range / ref に変えるのが基本

実行計画とは

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;

読み方の基本

1. 下から上、内側から外側に読む（PostgreSQL / Oracle のツリー表示）
2. 推定行数（rows / Cardinality）と実測の差が大きい行は統計情報が古いサイン
3. type=ALL / Seq Scan / TABLE ACCESS FULL が大表で出ていたらインデックス追加候補
4. Using filesort / Sort ノードが重ければ ORDER BY のキー / インデックスを再検討
5. 結合順序が想定と違うときはヒント句や統計収集を検討

典型的な改善パターン

症状	対処
WHERE のカラムでフルスキャン	そのカラムにインデックスを追加
関数 WHERE date(col)=... でインデックス無効	範囲条件に書き換え、もしくは関数インデックス
SELECT * で大きいカラムまで読む	必要列のみに絞り、カバリングインデックスで完結
結合順序が悪い	統計情報を最新化、駆動表を小さいほうに
推定行数が実測と乖離	MySQL: ANALYZE TABLE / Oracle: DBMS_STATS

関連

• パフォーマンスチューニング — 親カテゴリ
• インデックス — B-Tree / 複合 / カバリング
• 統計情報 — オプティマイザの判断材料
• クエリオプティマイザ — 実行計画を決める仕組み