データベースチューニングにおいて「どのSQLが遅いのか」だけでなく、「どの処理がボトルネックなのか」を正しく把握することは非常に重要です。
そのための基本ツールが**実行計画（EXPLAIN PLAN）**です。
本記事では、Oracleを例に実行計画の見方とボトルネックの探し方を、初心者でも理解できるように解説します。
✅ EXPLAIN PLANとは？
SQLを実行する際、Oracleが内部的に考える**最適な実行手順（アクセス方法）**を表示する機能です。
実行計画を見ることで、次のようなことがわかります。
-
テーブルにアクセスする順番
-
インデックスを使っているかどうか
-
結合（JOIN）の方式
-
フルスキャンが走っているか
-
コスト（予測負荷）
✅ 実行計画の取得方法
▼ 方法1：EXPLAIN PLAN文を使う
▼ 方法2：SQL Developer で「実行計画」ボタン
GUI環境ではワンクリックで参照できます。
✅ Oracle実行計画の基本構造
実行計画は階層構造で、上から順に処理が行われます。
インデントが深いほど「その処理の中で実行される詳細処理」です。
例：
✅ よく出るOperationと解釈ポイント
| Operation | 説明 | 見どころ |
|---|---|---|
| TABLE ACCESS FULL | テーブルの全件スキャン | 大量データで出たら要注意 |
| TABLE ACCESS BY INDEX ROWID | インデックス参照後にROWIDアクセス | 最適パターンの一つ |
| INDEX UNIQUE SCAN | 主キー・ユニークインデックス検索 | 高速 |
| INDEX RANGE SCAN | 範囲検索 | 効率的だが条件次第 |
| HASH JOIN | ハッシュ表でJOIN | 大量データ向き、メモリ消費 |
| NESTED LOOPS | 小規模データに適したJOIN | 結合相手の行数が多いと遅い |
| SORT ORDER BY | 並び替え | 必要ならOK、無駄がないか確認 |
✅ ボトルネックの探し方
① TABLE ACCESS FULL に注意
-
条件にインデックスが効いていない可能性
-
大規模テーブルで特に危険
対策：
-
WHERE句に使う列にインデックス追加
-
不必要な
SELECT *を避ける -
ファンクションインデックス
② JOIN方式を確認
| JOIN方式 | 特徴 | 適したケース |
|---|---|---|
| NESTED LOOPS | 小テーブル to 大テーブルに◎ | OLTP向き |
| HASH JOIN | 大量データ向き、高速 | DWH向き |
| MERGE JOIN | 並び替え前提、ソート負荷 | ソート後結合 |
Nested Loops × 大量データ → 遅い可能性
③ コスト（COST）とROWSを確認
| 項目 | 意味 |
|---|---|
| ROWS | 見積もられる行数 |
| COST | Oracleが見積もる負荷指数 |
| BYTES | データ量 |
COSTが極端に高い行がボトルネック候補。
④ SORTが多い場合
ORDER BY や DISTINCTが多いと遅くなる
対策：
-
必要な場面以外でDISTINCT使用しない
-
ORDER BYの列にインデックス
✅ 実例：遅いSQLの典型パターン
問題点
-
UPPER(ENAME)→ 関数でインデックス無効 -
LIKE ‘%〇〇’ → 前方ワイルドカードでインデックス無効
-
SELECT * → 不要な列読み込み
改善例
✅ チューニングの基本手順まとめ
| ステップ | 内容 |
|---|---|
| 1 | 実行計画を見る |
| 2 | TABLE FULL SCANをチェック |
| 3 | JOIN方法確認（Nested Loops vs Hash Join） |
| 4 | コスト高い箇所を特定 |
| 5 | インデックス／SQL修正 |
✅ まとめ
-
EXPLAIN PLANはSQLの動作設計図
-
インデックス利用とJOIN方式を重視
-
FULL SCANと高コスト行は警戒
-
必要な列だけ取得し、関数利用に注意
SQLチューニングは**「まず実行計画を見る」**がスタートです。
慣れるほど読み解きが早くなり、効率的な分析ができるようになります。
