「実行計画」タグアーカイブ

SQL, ブログ

SQL：実行計画（EXPLAIN PLAN）の読み方とボトルネックの見つけ方

2025年11月2日管理者コメントする

データベースチューニングにおいて「どのSQLが遅いのか」だけでなく、「どの処理がボトルネックなのか」を正しく把握することは非常に重要です。
そのための基本ツールが**実行計画（EXPLAIN PLAN）**です。

本記事では、Oracleを例に実行計画の見方とボトルネックの探し方を、初心者でも理解できるように解説します。

✅ EXPLAIN PLANとは？

SQLを実行する際、Oracleが内部的に考える**最適な実行手順（アクセス方法）**を表示する機能です。

実行計画を見ることで、次のようなことがわかります。

テーブルにアクセスする順番
インデックスを使っているかどうか
結合（JOIN）の方式
フルスキャンが走っているか
コスト（予測負荷）

✅ 実行計画の取得方法

▼ 方法1：EXPLAIN PLAN文を使う

▼ 方法2：SQL Developer で「実行計画」ボタン

GUI環境ではワンクリックで参照できます。

✅ Oracle実行計画の基本構造

実行計画は階層構造で、上から順に処理が行われます。
インデントが深いほど「その処理の中で実行される詳細処理」です。

例：

--------------------------------------------------------------------------------
| Id  | Operation                    | Name   | Rows  | Bytes | Cost (%CPU)|
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT             |        |     1 |    24 |     2   (0)|
|   1 |  TABLE ACCESS BY INDEX ROWID| EMP    |     1 |    24 |     2   (0)|
|   2 |   INDEX UNIQUE SCAN         | PK_EMP |     1 |       |     1   (0)|
--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 24 | 2 (0)|

| 1 | TABLE ACCESS BY INDEX ROWID| EMP | 1 | 24 | 2 (0)|

| 2 | INDEX UNIQUE SCAN | PK_EMP | 1 | | 1 (0)|

--------------------------------------------------------------------------------

✅ よく出る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チューニングは**「まず実行計画を見る」**がスタートです。
慣れるほど読み解きが早くなり、効率的な分析ができるようになります。

SQL, ブログ

インデックスの仕組みを理解してSQLを劇的に高速化する方法

2025年10月29日管理者コメントする

SQLの処理が遅いと感じたとき、多くの人が「サーバが遅いのでは？」と思いがちです。
しかし、実際の原因の多くは「インデックス（索引）」の使い方にあります。
この記事では、インデックスの基本構造から、実際のチューニング手法までを体系的に解説します。

1. インデックスとは？

インデックスとは、データベースが**検索を高速化するために作成する“索引”**のことです。
書籍の巻末索引のように、「この値はどこにあるか」を素早く見つけるための目次のような仕組みです。

🔹 例：インデックスなしの検索

このとき、インデックスが無ければ、データベースは全件を1件ずつ確認します（フルスキャン）。

🔹 例：インデックスありの検索

これにより、該当レコードを索引経由で一瞬で特定できるようになります。

2. インデックスの仕組みを理解する

🧩 B-treeインデックス

ほとんどのRDBMS（Oracle、MySQL、PostgreSQLなど）で採用されている構造です。
値が昇順に整理され、2分探索のように効率的に検索できます。

例えば「70」を探すとき、50より大きいので右に進み、次に70を発見します。
わずか2ステップで到達できるため、フルスキャンに比べて圧倒的に速いのです。

🧩 ビットマップインデックス（Oracleなど）

主に**値の種類が少ないカラム（性別、ステータスなど）**に有効です。
各値に対応するレコードのビットマップを管理することで、AND/OR検索が高速化します。

3. どんなカラムにインデックスを貼るべきか？

✅ 有効なケース

WHERE句で頻繁に検索される列
JOIN条件に使われる列
ORDER BYやGROUP BYの対象列
外部キー（FOREIGN KEY）列

🚫 不向きなケース

データ件数が極端に少ない列（例：性別など）
更新頻度が高い列（INSERT/UPDATEが多いと再構築コストが増大）
テーブル全件を常に取得するクエリ

4. 実行計画で確認する

SQLの速度改善は、**「インデックスが使われているか」**を確認することが第一歩です。

結果例（MySQLの場合）

type	key	rows	Extra
ref	idx_users_email	1	Using index

「Using index」と表示されていれば、インデックスが利用されています。
逆に「ALL」となっている場合はフルスキャンです。

5. インデックスを使った高速化テクニック

🌟 複合インデックス（複数列）

複数の列を組み合わせた検索で効果を発揮します。
ただし、先頭の列が条件に含まれないと使われない点に注意が必要です。

例：

🌟 カバリングインデックス（Covering Index）

インデックスに必要な列すべてを含めることで、テーブルアクセスをスキップできます。

テーブルを参照せずにインデックスだけで完結するため、極めて高速です。

🌟 LIKE検索の最適化

前方一致（Yui%）はインデックスが有効ですが、

のような部分一致はインデックス無効です。
対策としては、**全文検索エンジン（MySQLのFULLTEXT、PostgreSQLのGIN/GiST）**を使う方法があります。

6. 注意点：インデックスの弊害

インデックスは便利ですが、万能ではありません。
特に以下の点には注意が必要です。

リスク	説明
更新コスト増大	INSERTやUPDATE時にインデックスも更新されるため、処理が重くなる
ストレージ消費	大規模テーブルに多くのインデックスを張ると、容量が急増
メンテナンス負荷	不要なインデックスを放置すると、統計情報がずれて性能が劣化

🧹 定期的に ANALYZE TABLE や REBUILD INDEX を実施して、統計情報を更新しましょう。

7. 実践チューニング例

✏️ 例1：検索が遅いクエリ

🩹 改善策

✅ 実行計画の変化

変更前：type = ALL（フルスキャン）
変更後：type = ref（インデックス参照）

実行時間が数秒 → 数ミリ秒まで短縮されることもあります。

まとめ

ポイント	内容
インデックスとは	データ検索を高速化するための“索引”
構造	B-treeが主流。ビットマップは限定用途
効果的な付与	検索条件、JOIN、GROUP BY、ORDER BY列
落とし穴	更新負荷、容量増加、部分一致非対応
確認方法	EXPLAINで実行計画を必ずチェック

🚀 結論

インデックスを理解すれば、SQLの速度は10倍以上高速化することも珍しくありません。
なんとなく作るのではなく、「どう検索されるか」を意識して設計することが重要です。

SQL, ブログ

SQL：結合順序を意識してクエリ最適化を行う方法

2025年10月18日管理者コメントする

SQLでパフォーマンスを高めるうえで「結合順序（Join Order）」は非常に重要な要素です。
同じ結果を返すクエリでも、テーブルの結合順序によって処理時間が大きく変わることがあります。

この記事では、結合順序を意識したSQLの最適化方法を、実例とともにわかりやすく解説します。

🔍 なぜ結合順序が重要なのか

SQLの実行順序は見た目の記述順と異なり、最適化エンジンが最も効率的な順序を自動で選択します。
しかし、結合対象のテーブルサイズや結合条件によっては、自動最適化が必ずしも最適とは限りません。

特に以下のようなケースでは、結合順序が大きく影響します。

状況	パフォーマンスへの影響
大規模テーブルを先に結合している	不要なデータを大量に読み込む可能性
絞り込み条件のないテーブルを先に結合	フルスキャンのリスク
結合条件にインデックスが効いていない	結合ごとに多重ループが発生

🧩 結合順序の基本原則

一般的に、以下の順序を意識すると効率的です。

データ件数の少ないテーブルから結合する
WHERE句で絞り込めるテーブルを先に結合する
インデックスの効くテーブルを優先する
結合条件（ON句）は明確に指定する

例1：非効率な結合順序

この場合、employeesが数十万件あり、departmentsが数百件なら、
大テーブル→小テーブルの順になり、効率が悪くなります。

✅ 効率的な結合順序の書き方（例）

例2：効率的な書き方

先にdepartments（小テーブル）を起点にしてemployeesを結合すると、
条件に合う部署のみを先に絞り込めるため、結合コストを大幅に削減できます。

🧮 実行計画で結合順序を確認する

実際に最適化できているかを確認するには、**実行計画（EXPLAIN）**を確認します。

チェックポイント

項目	確認ポイント
type	ALL（全件走査）よりrefやindexが望ましい
rows	結合ごとの推定行数を確認し、不要な膨張がないか
Extra	Using where, "Using index" など最適化の有無を確認

⚙️ 結合順序の強制指定（ヒント句）

DBによっては**ヒント句（Hint）**を利用して結合順序を指定することも可能です。

Oracle の例

MySQL の例

STRAIGHT_JOINを使うと、記述順通りの結合順序で実行されます。

⚡ 実践Tipsまとめ

最適化ポイント	内容
小さいテーブルを先に結合	大量データの無駄読みを防ぐ
WHERE句の絞り込みを早期適用	不要データを結合前に排除
実行計画を確認	JOIN順序やインデックス利用を把握
ヒント句を活用	自動最適化がうまく働かない場合に使用

💡 まとめ

SQLの結合順序は、パフォーマンスチューニングの重要ポイントです。
自動最適化に頼るだけでなく、結合対象のデータ規模や条件を意識して設計することが大切です。
実行計画やヒント句を活用し、最適なクエリ構造を追求しましょう。

SQL, ブログ

SQL：インデックスヒント（INDEX HINT）でクエリ最適化を行う方法

2025年10月15日管理者コメントする

1. インデックスヒントとは？

SQLの**インデックスヒント（INDEX HINT）**とは、データベースに対して「このテーブルでは特定のインデックスを使用して実行してほしい」と明示的に指示するための構文です。
通常、DBエンジン（オプティマイザ）が自動で最適な実行計画を選びますが、統計情報が古い・複雑な条件句などの場合に誤ったインデックスを選ぶことがあります。

そのようなとき、開発者が明示的にインデックスを指定して最適化を誘導するのがINDEX HINTの目的です。

2. 一般的な書き方

Oracleの場合

MySQLの場合

SQL Serverの場合

データベース	ヒント指定方法	備考
Oracle	/+ INDEX(テーブル名インデックス名) /	ヒント句はコメント形式
MySQL	USE INDEX (インデックス名)	FORCE INDEX / IGNORE INDEX も可
SQL Server	WITH (INDEX(インデックス名))	テーブルヒントとして指定

3. MySQLにおけるINDEX HINTの種類

種類	意味	使用例
USE INDEX	指定したインデックスを優先的に使用	USE INDEX (idx_col1)
FORCE INDEX	指定インデックスを強制的に使用	FORCE INDEX (idx_col1)
IGNORE INDEX	指定インデックスを無視して検索	IGNORE INDEX (idx_col1)

4. 実行計画を確認する

インデックスヒントを付与したら、実際に利用されているかを確認することが重要です。

MySQL

Oracle

EXPLAIN PLAN FOR
SELECT /*+ INDEX(employees emp_dept_idx) */ * FROM employees WHERE department_id = 10;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

EXPLAIN PLAN FOR

SELECT /*+ INDEX(employees emp_dept_idx) */ * FROM employees WHERE department_id = 10;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

チェック項目	内容
key列（MySQL）	使用されたインデックス名
access path（Oracle）	INDEX RANGE SCAN などが表示される
実行コスト	コストが下がっているか確認

5. 使用上の注意点

注意点	内容
1. 過信しない	ヒントは一時的なチューニングであり、将来的な統計情報変化で逆効果になることも。
2. 実行計画を常に確認	ヒント適用後は EXPLAIN で確認すること。
3. SQL互換性に注意	各DBMSで構文が異なるため、移植性が下がる。
4. ヒント指定よりも統計情報更新が基本	統計情報を更新することで自動最適化が正しく働くことも多い。

6. 実用例：複合インデックスを明示的に使用

以下のように複数条件を持つ検索で、DBが誤ったインデックスを選ぶ場合に有効です。

このように、複合インデックスの指定順序に合わせてヒントを指定することで、不要な全件スキャンを防ぐことができます。

7. まとめ

ポイント	内容
自動最適化が基本	まずはDBエンジンに任せるのが原則
ヒントは最終手段	特定クエリで誤選択時のみ使用
EXPLAINで検証	効果を数値で確認
統計情報更新も忘れずに	オプティマイザの精度を保つために重要

SQL, ブログ

SQL：IN句からEXISTS句への変換方法

2022年6月9日管理者コメントする

IN句をEXISTS句へ変換するとパフォーマンスが向上すると言われることがあるので

IN句からEXISTS句への変換例をメモしておきます。

サンプルテーブル

以下の商品テーブル「goods」と属性コードテーブル「type_code」を元に説明します。

商品テーブル「goods」	属性コードテーブル「type_code」
"	"

IN句を使用したSQL例

商品テーブル「goods」のtype_codeが ‘101’で属性コードテーブル「type_code」にも存在する商品名を取得する例となります。

SELECT tc.code_name
FROM type_code AS tc
WHERE
 tc.code IN(SELECT type_code FROM goods WHERE type_code = '101');

SELECT tc.code_name

FROM type_code AS tc

WHERE

tc.code IN(SELECT type_code FROM goods WHERE type_code = '101');

EXISTS句を使用したSQL例

WHERE句後の「tc.code IN」を「EXISTS」に変更し、「AND type_code = tc.code」を追加しただけです。

SELECT tc.code_name
FROM type_code AS tc
WHERE 
 EXISTS
 (SELECT 1 FROM goods WHERE type_code = '101' AND type_code = tc.code);

SELECT tc.code_name

FROM type_code AS tc

WHERE

EXISTS

(SELECT 1 FROM goods WHERE type_code = '101' AND type_code = tc.code);

出力結果（IN句、EXISTS句）

IN句、EXISTS句どちらの場合も以下の結果となります。

NOT EXISTS句を使用したSQL例

EXISTS句は使い慣れてないと今一つ分かりにくい気がするので、上記のEXISTSをNOT EXISTSで実行してみた例も記載しておきます。なんとなくEXISTSがどういう結果を出力しているかわかるかも。。

SELECT tc.code_name
FROM type_code AS tc
WHERE 
 NOT EXISTS(SELECT 1 FROM goods WHERE type_code = '101' AND type_code = tc.code);

SELECT tc.code_name

FROM type_code AS tc

WHERE

NOT EXISTS(SELECT 1 FROM goods WHERE type_code = '101' AND type_code = tc.code);

出力結果（NOT EXISTS句）

NOT EXISTS句の結果は以下となります。

補足

本稿では、 IN句から EXISTS句への変換例およびその基本的な使い分けを紹介しましたが、実運用においては以下の点にもご留意ください。

データベース製品（たとえば PostgreSQL／Oracle Database／MySQL）やバージョンによって、IN句とEXISTS句の内部実行プランや最適化状況が異なるため、単純に「INは遅い」「EXISTSの方が速い」と一律判断するのは危険です。
実際には、サブクエリの対象件数・インデックス構成・統計情報の鮮度などがパフォーマンスに大きく影響します。EXISTSに変えたからといって必ずしも高速化するとは限りません。
また、可読性・保守性の観点からは「どちらが読みやすいか・将来変更しやすいか」も考慮に入れるべきです。たとえば、複雑な条件・結合・集計を伴うSQLでは、意図が明確な記述を優先したほうがトラブルを防げます。
最後に、SQLのチューニングは「手段」ではなく「目的」—つまり、「実際の業務で期待されるレスポンスタイムを満たしているか」「運用負荷を適切にコントロールできているか」という観点が最も重要です。この点を忘れず、必要に応じて実行計画の確認やプロファイリングを実施してください。

引き続き、SQL設計・実装・運用の改善にお役立ていただければ幸いです。
今後も他の観点（たとえば JOINの最適化／ウィンドウ関数の活用／データ量に対するスケーリング）についても、機会を改めてご紹介したいと思います。

✅ EXPLAIN PLANとは？

✅ 実行計画の取得方法

▼ 方法1：EXPLAIN PLAN文を使う

▼ 方法2：SQL Developer で「実行計画」ボタン

✅ Oracle実行計画の基本構造

✅ よく出るOperationと解釈ポイント

✅ ボトルネックの探し方

① TABLE ACCESS FULL に注意

② JOIN方式を確認

③ コスト（COST）とROWSを確認

④ SORTが多い場合

✅ 実例：遅いSQLの典型パターン

問題点

改善例

✅ チューニングの基本手順まとめ

✅ まとめ

関連記事

1. インデックスとは？

🔹 例：インデックスなしの検索

🔹 例：インデックスありの検索

2. インデックスの仕組みを理解する

🧩 B-treeインデックス

🧩 ビットマップインデックス（Oracleなど）

3. どんなカラムにインデックスを貼るべきか？

✅ 有効なケース

🚫 不向きなケース

4. 実行計画で確認する

結果例（MySQLの場合）

5. インデックスを使った高速化テクニック

🌟 複合インデックス（複数列）

🌟 カバリングインデックス（Covering Index）

🌟 LIKE検索の最適化

6. 注意点：インデックスの弊害

7. 実践チューニング例

✏️ 例1：検索が遅いクエリ

🩹 改善策

✅ 実行計画の変化

まとめ

🚀 結論

関連記事

🔍 なぜ結合順序が重要なのか

🧩 結合順序の基本原則

例1：非効率な結合順序

✅ 効率的な結合順序の書き方（例）

例2：効率的な書き方

🧮 実行計画で結合順序を確認する

チェックポイント

⚙️ 結合順序の強制指定（ヒント句）

Oracle の例

MySQL の例

⚡ 実践Tipsまとめ

💡 まとめ

関連記事

1. インデックスヒントとは？

2. 一般的な書き方

Oracleの場合

MySQLの場合

SQL Serverの場合

3. MySQLにおけるINDEX HINTの種類

4. 実行計画を確認する

MySQL

Oracle

5. 使用上の注意点

6. 実用例：複合インデックスを明示的に使用

7. まとめ

関連記事

サンプルテーブル

IN句を使用したSQL例

EXISTS句を使用したSQL例

出力結果（IN句、EXISTS句）

NOT EXISTS句を使用したSQL例

出力結果（NOT EXISTS句）

補足

関連記事

「駑馬十駕」を信念に IT系情報を中心に調べた事をコツコツ綴っています。

　関連記事

　関連記事

　関連記事

　関連記事

　関連記事