最終更新日：2026年10月1日
fe fe-technology database sql
まず結論
SQLオプティマイザ（optimizer）とは、SQLを実行するときに考えられる複数の方法を比較し、効率がよいと見積もられる実行計画（execution plan）を選ぶDBMSの機能です。
基本情報技術者試験では、次の表現が出たらオプティマイザを疑います。
SQLを実行する
＋
複数のアクセス経路・実行方法がある
＋
効率がよい方法を選ぶ
→ オプティマイザ
例えば、同じ検索でも、
表を先頭から順番に調べる
→ 全表走査
インデックスを使って目的の行へ近づく
→ インデックス利用
など、複数の方法が考えられます。
オプティマイザは、それらの候補を評価し、適切と見積もられる実行計画を選びます。
直感的な説明
オプティマイザは、目的地までの経路を選ぶカーナビのようなものです。
目的地は同じでも、行き方は一つとは限りません。
目的地
↓
一般道
高速道路
迂回路
↓
条件を見て経路を選ぶ
SQLも同じです。
例えば、
SELECT *
FROM employees
WHERE employee_id = 100;
というSQLがあったとします。
DBMS内部では、
方法A
→ 表を最初から最後まで読む
方法B
→ employee_id のインデックスを使う
などの実行方法を考えられます。
どちらがよいかは、データ件数、インデックスの有無、値の分布などによって変わります。
図で確認：SQLから実行計画が決まるまで
「何を取り出すか」はSQLで指定し、「どう取り出すか」はDBMS内部で決めます。
取得したい結果を指定
候補の実行方法を評価
選ばれた方法で実行
このテーマでは、操作よりもSQL → オプティマイザ → 実行計画の役割分担を理解することが重要なので、JavaScriptは増やさずCSSの静的図解で整理しています。
定義・仕組み
実行計画とは
実行計画とは、SQLをどのような手順で処理するかを表した計画です。
代表的には、次のような内容が関係します。
- 表をどの順番で読むか
- インデックスを使うか
- 全表走査するか
- 複数の表をどの順番で結合するか
- どの結合方式を使うか
SQL
↓
候補となる実行方法を考える
↓
コストなどを評価する
↓
実行計画を選ぶ
↓
実行
ここで大切なのは、SQL文そのものが「インデックスを必ず使え」と指定しているわけではないという点です。
DBMSは、SQLの意味を満たす範囲で、内部の実行方法を選びます。
インデックスがあっても必ず使うとは限らない
インデックスは検索を速くするための索引ですが、常に使う方が速いとは限りません。
例えば、表の大部分の行を読む必要がある場合は、
インデックスを何度もたどる
よりも、
表をまとめて順番に読む
方が効率的な場合があります。
したがって、
インデックスがある = 必ずインデックスを使う
ではありません。
インデックスそのものの役割は、インデックスとは？検索を速くするデータベースの索引で整理しています。
コストベースとルールベース
オプティマイザの考え方として、試験では次の違いを押さえると分かりやすいです。
| 方式 | 判断の考え方 |
|---|---|
| ルールベース | あらかじめ定められた規則や優先順位をもとに選ぶ |
| コストベース | 統計情報などから処理コストを見積もり、低いものを選ぶ |
コストベースでは、例えば次のような情報が判断材料になります。
- 表の行数
- 値の分布
- インデックスの有無
- 選択される行数の見積り
FEではDBMS固有の細かな計算式よりも、
規則で選ぶ
→ ルールベース
統計情報などから処理量を見積もる
→ コストベース
と切り分けられれば十分です。
「全ての実行計画を試す」とは限らない
初心者向けの説明で「考えられる実行計画を全部試す」と表現されることがありますが、厳密には注意が必要です。
表の数や結合方法が増えると、候補の組合せは非常に多くなります。
そのため実際のDBMSでは、候補を探索・評価し、適切と見積もられる計画を選ぶと考えるのが安全です。
「全候補を実行して比べる」のではなく、「実行前に候補のコストを見積もって選ぶ」と理解する。
科目Aでどう出る？
科目Aでは、説明文からオプティマイザを選ぶ用語問題として出ることがあります。
最も強い判断キーワードは、
SQL
アクセス経路
実行計画
効率のよい方法を選ぶ
です。
選択肢は「何を最適化・処理しているか」で切る
| 説明 | 用語 |
|---|---|
| SQLのアクセス経路や実行計画を選ぶ | オプティマイザ |
| 不要になったメモリ領域を自動回収する | ガーベジコレクション |
| 似ているデータをグループ分けする | クラスタリング |
| データを分割・併合しながら整列する | マージソート |
試験中は次のように短く置き換えます。
SQLの実行方法を選ぶ
→ オプティマイザ
不要メモリを回収
→ ガーベジコレクション
似たものをまとめる
→ クラスタリング
並べ替える
→ ソート
「インデックスを使う機能」とだけ覚えない
オプティマイザの仕事は、インデックスを使うことだけではありません。
インデックスを使うか
全表走査するか
どの順番で表を結合するか
どの結合方式を使うか
など、SQL全体の実行方法を考えます。
したがって、
「オプティマイザ = インデックスを使う機能」ではなく、「実行計画を選ぶ機能」
と覚えます。
どんな場面で使う？
オプティマイザは、DBMSがSQLを効率よく実行するときに働きます。
利用者は通常、
SELECT ...
FROM ...
WHERE ...;
のように「欲しい結果」をSQLで指定します。
一方、DBMS内部では、
どの表から読むか
どのインデックスを使うか
どう結合するか
を決める必要があります。
この判断を担うのがオプティマイザです。
また、SQLが遅いときには、実行計画を確認して、
- 全表走査になっていないか
- 想定したインデックスが使われているか
- 結合順序が適切か
などを調べます。
データベース性能低下の原因を広く切り分ける場合は、データベース性能低下の原因と調査方法も参照してください。
よくある誤解・混同
オプティマイザはSQL文を書き換える機能？
「効率よく実行する」という点では近く見えますが、FEではまず実行計画を選ぶ機能として理解します。
SQLで指定された結果を変えるのではなく、その結果を得るための内部の処理方法を決めます。
インデックスがあれば必ず使う？
必ずではありません。
表の多くの行を読む場合など、全表走査の方が効率的と見積もられることもあります。
インデックスあり
→ 必ず利用する、ではない
コストを評価
→ より適切な方法を選ぶ
オプティマイザは実行後に速かった方法を選ぶ？
基本的な理解としては違います。
実行前に統計情報などを使ってコストを見積もり、実行計画を決めます。
クラスタリングと同じ「最適化」の仲間？
違います。
クラスタリングは、特徴の似たデータをグループ分けする分析手法です。
SQLの実行方法を選ぶオプティマイザとは目的が異なります。
コンパイラの最適化と同じ？
どちらも「効率のよい実行」を目指しますが、対象が違います。
SQLオプティマイザ
→ SQLの実行計画
コンパイラ最適化
→ プログラムコードや生成される機械語
試験では「何を最適化しているか」を確認します。
公式ドキュメントで確認する
オプティマイザの実装はDBMSによって異なります。具体例として、PostgreSQLの公式ドキュメントでは、EXPLAINによってクエリプランを確認でき、プランナが統計情報などを利用して実行計画を選ぶ仕組みを確認できます。
FE試験では、PostgreSQL固有の表示形式を覚える必要はありません。
「SQLには複数の実行方法があり、オプティマイザが効率を見積もって実行計画を選ぶ」という役割を優先します。
確認問題（基本情報技術者試験対策）
SQLを実行するとき、表の走査方法やインデックス利用、結合順序などの候補を評価し、効率がよいと見積もられる実行計画を選択するDBMSの機能はどれか。
- ア. オプティマイザ
- イ. ガーベジコレクション
- ウ. クラスタリング
- エ. マージソート
▶ クリックして答えと解説を見る（ここを開く）
正解：ア
オプティマイザは、SQLの複数の実行方法を評価して、効率がよいと見積もられる実行計画を選びます。
SQL
↓
オプティマイザ
↓
実行計画
↓
実行
- ガーベジコレクションは不要メモリの回収
- クラスタリングは似たデータのグループ化
- マージソートは整列アルゴリズム
です。
まとめ（試験直前用）
- オプティマイザは、SQLの効率的な実行計画を選ぶDBMSの機能
- 実行計画には、全表走査・インデックス利用・結合順序などが関係する
- インデックスがあっても必ず使うとは限らない
- ルールベースは規則、コストベースは統計情報などからコストを見積もる
- 「全ての計画を実行して試す」とは限らず、候補を探索・評価して選ぶ
- 試験では 「SQL・アクセス経路・実行計画・効率のよいものを選ぶ」 が判断キーワード
一言で覚えるなら、
SQLオプティマイザ = SQLの「どう実行するか」を決める機能。