情報処理試験を勉強していると、「インデックスって結局何？B木とB+木の違いは？」と混乱しがちです。この記事では、データベースのインデックスの仕組みと種類を、日常の例え話と図解で整理します。

目次 [ close ]
  1. 対象試験と出題頻度
  2. 用語の定義
  3. 解説
    1. B木とB+木の仕組み
    2. インデックスの種類と比較
    3. CREATE INDEX文の構文
  4. 試験ではこう出る！
  5. 【確認テスト】理解度チェック
  6. よくある質問（FAQ）

対象試験と出題頻度

インデックス（B木インデックスなど）は、基本情報技術者・応用情報技術者で出題されるテーマです。

DBMSの内部構造やSQL性能に関わる問題として定番化しており、「B+木インデックスが有効な検索パターン」「ハッシュインデックスとの使い分け」が繰り返し問われています。

詳細をクリックして確認
対象試験：
基本情報技術者
応用情報技術者
出題頻度：
★★★☆☆
ランクB（標準）覚えておくと有利

用語の定義

インデックス（Index）とは、一言で言うと

　「データベースの検索を高速化するために、テーブルとは別に作成する索引構造」

のことです。

イメージとしては、「辞書の巻末索引」です。

500ページの辞書から「B木」という言葉を探すとき、1ページ目から順にめくっていたら日が暮れます。巻末索引で「B」の欄を見れば「B木 → 278ページ」と一発で分かります。

データベースのインデックスも同じ役割を果たし、目的のデータがある行の位置情報をあらかじめ整理しておくことで、全行を走査せずに高速検索を実現します。

📊 インデックスの基本情報

項目 内容
英語名 Index
目的 データ検索の高速化（SELECT文の性能向上）
作成方法 CREATE INDEX文（DDLに分類される）
代表的な種類 B+木インデックス、ハッシュインデックス、ビットマップインデックス、転置インデックス
トレードオフ 検索は速くなるが、挿入・更新・削除時にインデックスの更新コストが発生する

解説

SELECT文を実行すると、RDBMSは該当するデータを探しに行きます。テーブルの行数が少なければ全行を順番に走査（フルテーブルスキャン）しても一瞬ですが、数百万行のテーブルでは処理時間が無視できなくなります。

この問題を解決するのがインデックスです。あらかじめ「どのキー値がどの行にあるか」を別の構造で整理しておくことで、必要な行だけを素早く特定できるようになります。

B木とB+木の仕組み

RDBMSで最も広く採用されているのがB+木（B-plus Tree）インデックスです。その土台であるB木（B-Tree）から順に見ていきます。

そもそもB木とは

B木は「平衡多分木」と呼ばれる木構造です。通常の2分木は子を最大2つしか持てませんが、B木では1つのノードに複数のキー値を格納し、子を3つ以上持てます。そして最大の特徴は、すべての葉ノードが同じ深さに揃っている（平衡している）点です。

データが偏っても木の一方だけが深くなることがなく、どのキー値を検索しても同じ段数でたどり着けます。

B+木はB木の何を改良したのか

B+木はB木を発展させた構造で、2つの大きな違いがあります。

比較項目 B木 B+木
データの格納場所 根・中間・葉のすべてのノードにデータ（行への位置情報）を格納 葉ノードだけにデータを格納。根・中間ノードはキー値と子へのポインタのみ持つ
葉ノードの連結 葉ノード同士の連結なし 葉ノード同士がポインタで連結されている（→ これが範囲検索を高速にする）
範囲検索 木を何度もたどり直す必要があり非効率 葉を横方向にたどるだけでよく高速
RDBMSでの採用 そのままの形ではほぼ使われない MySQL・PostgreSQL・Oracleなど主要RDBMSの標準

ここだけは確実に押さえてください。B+木の最大のポイントは「データは葉だけ、葉は横につながっている」です。

図解：B+木インデックスの全体構造

以下の図で、各ノードの役割と接続関係を色分けして示します。

根ノード（ルート） 中間ノード 葉ノード ＝ データがある層 ⇄ 葉の横方向ポインタ
<30 30〜59 ≥60 根ノード 30 ｜ 60 中間ノード 10 ｜ 20 中間ノード 40 ｜ 50 中間ノード 70 ｜ 80 葉 5,8 葉 10,15 葉 20,25 葉 30,35 葉 40,45 葉 50,55 葉 60,65 葉 70,75 葉 80,90 読み方のポイント： 根・中間ノードは「道しるべ」。キー値の範囲で「この子へ進め」と振り分けるだけ 葉ノードだけが実際のデータの場所（行への位置情報）を持っている 葉同士が ⇄ で横に連結 → 範囲検索では葉を横にたどるだけで済む

具体例：「キー値 = 45」を検索する流れ

実際にB+木の中を検索がどのように進むか、1ステップずつ追いかけてみます。

検索：WHERE id = 45 ❶ 根ノード 30 ｜ 60 10 ｜ 20 ❷ 中間ノード 40 ｜ 50 70 ｜ 80 … 30,35 ❸ 葉 40, 45 50,55 … たった3回のアクセスで到達 ─ 10万行でも深さ4〜5段で済む
❶ 根ノード
45は30以上60未満
→ 中央の子へ
❷ 中間ノード
45は40以上50未満
→ 中央の子へ
❸ 葉ノード
45を発見！
→ 行の位置情報で検索完了

具体例：「キー値が40以上60未満」を範囲検索する流れ

B+木が範囲検索に強い理由を、実際の動きで確認します。

検索：WHERE id BETWEEN 40 AND 59 ❶ 根ノード 30 ｜ 60 10 ｜ 20 ❷ 中間ノード 40 ｜ 50 70 ｜ 80 … 30,35 ❸ 葉 40,45 ❹ 葉 50,55 STOP 60,65 … 縦移動3回 ＋ 横移動2回 ＝ 計5回で完了 ─ 木を上からたどり直す必要なし
❶❷ 縦移動
根→中間→葉で
下限値40の位置を特定
❸❹ 横移動
葉の⇄ポインタで
右隣[50,55]も取得
STOP
[60,65]は範囲外
→ ここで検索終了

図解：B木 vs B+木 ― 構造の違いを並べて比較

B木（B-Tree） 30 +data 10 +data 50 +data 5 +data 20 +data 40 +data 60 +data ● 全ノードに+dataあり ● 葉同士の横リンクなし ● 範囲検索は木を何度もたどる必要あり B+木（B-plus Tree）← RDBMSの標準 30 ポインタのみ 10 ポインタのみ 50 ポインタのみ 5 +data 20 +data 40 +data 60 +data ● データは葉だけ（+dataは葉のみ） ● 葉同士が ⇄ で横連結 ● 範囲検索は葉を横にたどるだけで高速

この「データは葉だけ、葉は横につながっている」という構造が、B+木がRDBMSの標準として採用されている最大の理由です。

インデックスの種類と比較

B+木以外にも代表的な種類があります。ここだけは確実に押さえてください。

種類 仕組み 得意な検索 苦手な検索
B+木 平衡木で葉が連結された構造 一致検索、範囲検索、ORDER BY 否定条件（!=）、NULL検索
ハッシュ ハッシュ関数でキー値から格納位置を直接算出 完全一致検索（= での1件検索） 範囲検索、ソート、前方一致
ビットマップ キー値ごとにビット配列を作成 カーディナリティが低い列（性別・フラグ等） 更新頻度が高い列
転置 単語→出現位置の対応を格納 全文検索 数値の範囲検索
何となくで覚えたい人向け：B+木とハッシュの使い分け早見表
検索パターン B+木 ハッシュ
WHERE id = 1001 ○ ◎（より高速）
WHERE price BETWEEN 1000 AND 5000 ◎ ×
WHERE name LIKE ‘A%’ ○ ×
WHERE code != 1001 × ×
ORDER BY date ◎ ×

◎＝最適 ○＝有効 ×＝効果なしまたは使用不可

CREATE INDEX文の構文

インデックスはCREATE文で作成します。基本構文は以下の通りです。

— インデックスの作成

CREATE INDEX idx_maker_code

ON 部品 (メーカーコード);

— インデックスの削除

DROP INDEX idx_maker_code;

では、この用語が試験でどのように出題されるか見ていきましょう。

💡 インデックスの核心を3行で

・テーブルとは別に作る索引構造で、検索を高速化する代わりに更新コストが増える
・B+木は範囲検索・一致検索の両方に対応するRDBMSの標準的な方式
・ハッシュは完全一致のみ高速、ビットマップは低カーディナリティ列向け

試験ではこう出る！

インデックスは、FE・APの午前問題でデータベース分野の定番テーマとして繰り返し出題されています。出題パターンは大きく2つに分かれます。

📊 過去問での出題実績

試験回 出題内容 問われたポイント
FE H27秋
午前 問26		 異なるキー値でも同一の算出結果になる可能性がある方式を選ぶ問題 ・正解はハッシュインデックス
・B+木・転置・ビットマップがひっかけ
FE H26秋
午前 問27		 B+木よりハッシュが適切な検索処理を選ぶ問題 ・正解は完全一致の1件検索
・範囲検索・前方一致はB+木向き
AP H30秋
午前 問29		 B+木インデックスで性能改善が期待できる操作を選ぶ問題 ・正解は範囲検索（BETWEEN）
・否定条件やNULL検索は効果なし
AP R5秋
午前 問26		 FE H26秋 問27と同一構成の問題（流用） ・FEとAPで同じ問題が出回る典型例
・選択肢構成もほぼ同一

📝 IPA試験での出題パターン

パターン1：「B+木インデックスが有効な操作を選べ」
テーブルとデータの条件が提示され、B+木で性能改善が期待できる検索を選ぶ形式。ひっかけとして「否定条件（!=）」や「NULLを含む条件」が並ぶ。キーワードは「範囲検索」「BETWEEN」。否定・NULLでは効果を発揮しないと即座に除外できれば正解にたどり着けます。

 

パターン2：「ハッシュインデックスが適切なものを選べ」
B+木とハッシュの使い分けを問う形式。ハッシュが有効なのは「完全一致の1件検索」だけ。範囲検索・前方一致・ソートが含まれる選択肢はすべてB+木向きなので除外します。

 

試験ではここまででOKです。B+木の内部構造（ノード分割アルゴリズムなど）は問われないので、深追いは不要です。

【確認テスト】理解度チェック

ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。

Q. “売上”表の利用者ID列に対してインデックスを設定する。B+木インデックスよりもハッシュインデックスの方が適切な検索処理はどれか。

  • A. 利用者IDが’1001’以上’2000’以下の売上を検索する。
  • B. 利用者IDが’1001’の売上を検索する。
  • C. 利用者IDの昇順に売上を並び替えて取得する。

正解と解説を見る

正解：B

解説：
ハッシュインデックスは、ハッシュ関数でキー値から格納位置を直接算出する方式です。特定のキー値に完全一致する1件を探す処理ではB+木より高速にアクセスできます。

選択肢Aは範囲検索（BETWEEN相当）であり、ハッシュは範囲検索に対応できないためB+木が適切です。選択肢Cはソート（ORDER BY相当）であり、ハッシュではキー値の順序情報を保持しないため対応できません。これもB+木が適切な処理です。

よくある質問（FAQ）

Q. インデックスを作りすぎるとどうなりますか？

SELECT文の検索速度は上がりますが、INSERT・UPDATE・DELETE文の実行時にインデックスも同時に更新されるため、書き込み性能が低下します。また、インデックス自体がディスク容量を消費します。実務では「検索頻度が高い列」「WHERE句やJOIN句で頻繁に指定する列」に絞って作成するのが基本方針です。

Q. 主キーにインデックスは自動で作られますか？

はい。ほとんどのRDBMS（Oracle、MySQL、PostgreSQLなど）では、主キー制約を定義すると自動的に一意インデックスが作成されます。そのため、主キー列に手動でCREATE INDEXを実行する必要はありません。UNIQUE制約を付けた列にも同様に一意インデックスが自動生成されるのが一般的です。

Q. B木とB+木は試験で区別する必要がありますか？

IPA試験（FE・AP）の午前問題では、ほぼすべて「B+木インデックス」として出題されており、B木単体との厳密な違いを問う問題は出ていません。「B+木は葉ノードにだけデータがあり、葉同士がポインタで連結されているから範囲検索に強い」という点を理解していれば十分です。データベーススペシャリスト試験では探索回数のオーダー（logN）が問われることもありますが、FE・APでは試験範囲外です。

Q. 「シノニム」とインデックスの関係は？

シノニム（衝突）とは、ハッシュ関数で異なるキー値が同じ格納位置に算出されてしまう現象です。FE H27秋 午前問26では、まさに「異なったキー値でも同一の算出結果となる可能性がある方式はどれか」と出題され、正解がハッシュインデックスでした。B+木では木構造で位置を決めるためシノニムは発生しません。