実行計画 | DB試験対策

実行計画とは

オプティマイザが SQL を実行する際に選んだ具体的な手順のツリー。EXPLAIN コマンドで確認でき、性能チューニングの最初の一歩。

SQL は「何を取りたいか」を書くが、「どうやって取るか」はオプティマイザが決める。実行計画はその「どうやって」を可視化するもの。

EXPLAIN の使い方と読み方

EXPLAIN SELECT * FROM 受注 WHERE 顧客ID = 'C01';

-- PostgreSQL の例（概念的な出力）
-- Index Scan using idx_顧客ID on 受注
--   Index Cond: (顧客ID = 'C01')
--   cost=0.43..4.45 rows=1 width=80

主要な操作（オペレーター）一覧

操作名	意味	性能
Index Scan / Index Seek	インデックスを使った検索	✅ 速い
Seq Scan / Full Table Scan	テーブル全行スキャン	⚠ 大テーブルで遅い
Index Only Scan	インデックスだけで完結（カバリング）	✅✅ 最速
Nested Loop	ネストループ結合	内側にインデックスで高速
Hash Join	ハッシュ結合	大テーブル同士に有効
Sort	ソート操作	メモリ超過でディスク使用
Bitmap Heap Scan	ビットマップを作ってからヒープ読み込み	中規模の IN 条件等

コストベースオプティマイザの仕組み

① SQL をパース（構文解析）して内部表現に変換

↓

② 論理的に等価な実行プランの候補を列挙

↓

③ 統計情報（テーブル行数・カーディナリティ・列のヒストグラム）を使ってコストを推定

↓

④ コストが最小のプランを選択して実行

統計情報が古いと誤ったプランが選ばれる。定期的に ANALYZE（PostgreSQL）/ UPDATE STATISTICS（SQL Server）を実行する。

コストの読み方

cost=0.43..8.45 rows=10 width=80 の意味

項目	意味
cost=0.43	最初の行を返すまでのコスト（スタートアップコスト）
cost=..8.45	全行を返し終えるまでの総コスト
rows=10	返される推定行数
width=80	1 行あたりの推定バイト数

コストは単位（ディスクページ読み込み）を基準とした相対値。絶対値より親ノードと子ノードの大小関係が重要。

よくある問題と改善策

実行計画を見て行うチューニング

実行計画の症状	原因	改善策
Full Table Scan / Seq Scan	インデックスなし・統計情報古い	インデックス追加・ANALYZE 実行
Sort（大量行）	ORDER BY / GROUP BY 列にインデックスなし	ソート列にインデックス追加
Hash Batches > 1	ハッシュ表がメモリに収まらない	work_mem 増加・結合順序変更
rows 推定値と実際値の乖離	統計情報が古い	ANALYZE / UPDATE STATISTICS

ヒント句による手動チューニング

-- Oracle のヒント句（最終手段）
SELECT /*+ INDEX(c idx_顧客名) */
  c.顧客ID, c.顧客名
FROM   顧客 c
WHERE  c.顧客名 = '山田';

ヒント句はオプティマイザを上書きするため、統計情報を更新したりインデックスを変更するほうが先。ヒント句への依存はメンテナンスコストを上げる。

試験頻出ポイント

EXPLAIN でオペレーターの種類・コスト・推定行数を確認
Seq Scan → インデックス追加か統計情報更新を検討
統計情報が古い → オプティマイザが誤ったプランを選ぶ
インデックスがあっても全行の大部分を返す場合は Seq Scan が選ばれる（選択率が高い）
EXPLAIN ANALYZE（実際に実行して推定と実測を比較）も重要

📝 理解度チェック

コストベースオプティマイザが実行計画を選択する基準はどれか？

実行計画で Seq Scan（フルスキャン）が出た場合に最初に確認すべきことはどれか？

統計情報が古い場合に発生する問題はどれか？

読了ボタンを押すとトップページの進捗に反映されます

← インデックスの種類性能設計 →