発展インデックスの種類

カバリングインデックス

定義

カバリングインデックスとは、クエリで参照する全カラムをインデックス側だけで賄えるように設計したもので、テーブル本体アクセス(インデックスオンリースキャン)を不要にする。

「テーブル本体を読まない」インデックス

通常のインデックス検索は、インデックスで該当行を特定してからテーブル本体にアクセスして必要なカラムを取り出します。 カバリングインデックスは、必要なカラムをインデックス側に全部含めることで、テーブル本体アクセスを一切不要にします。

カバリングインデックス(インデックスオンリースキャン)
インデックス (user_id, order_id)

※ ここでは分かりやすさのためソート済みリスト風に描いているが、 実際はB-treeで保持されるので探索は O(log N)。 詳しくは B-treeの仕組み へ。

user_id=1order_id=1001→ 本体を読む
user_id=1order_id=1002→ 本体を読む
user_id=2order_id=1003→ 本体を読む
user_id=3order_id=1004→ 本体を読む
該当行の本体ページを追加で読み取る
テーブル本体
user_id=1order_id=1001amount=50002025-01-01
user_id=1order_id=1002amount=12002025-01-03
user_id=2order_id=1003amount=88002025-01-05
user_id=3order_id=1004amount=33002025-01-06

amount を取得するために、インデックスで見つけた各行についてテーブル本体を追加アクセスする(Row Lookup)。

クエリ SELECT amount FROM orders WHERE user_id = 1 を想定。カバリングにすると amount がインデックスに含まれるためテーブル本体を読む必要が無くなる。

省略されているのは「テーブル本体のページ読み取り」

通常のインデックスは、葉ノードから 行ID を取得したあと、そのIDが指すページを読みに行きます。この追加のページI/Oが、行数が多いクエリでは支配的な時間になる。

通常インデックス: 追加のページ読み取りが発生
B-tree 葉ノードkey = 42→ 行ID (page=1, offset=0)ページ読み込みテーブル本体 Page 1(約8KB)offset 0 · id=42 · Sato · sato@example.comoffset 1 · id=15 · Tanaka · tanaka@example.comoffset 2 · id=83 · Suzuki · suzuki@example.comoffset 3 · id=27 · Ito · ito@example.comインデックスから行IDを取得そのページを読んで該当行を取り出す

カバリングにすると、必要な値がインデックス側に入っているため、この「テーブル本体のページを読む」ステップを完全に省略できます。

カバリング: インデックスだけで完結(ページ読まない)
カバリング葉ノードkey = 42→ 行ID (page=1, offset=0)+ name="Sato"不要テーブル本体 Page 1(約8KB)offset 0 · id=42 · Sato · sato@example.comoffset 1 · id=15 · Tanaka · tanaka@example.comoffset 2 · id=83 · Suzuki · suzuki@example.comoffset 3 · id=27 · Ito · ito@example.com1回のI/O(インデックスだけ)本体ページは読まない

「インデックスオンリースキャン」と呼ばれる

実行計画(EXPLAIN)に「テーブル本体を触っていない」ことを示す文言が現れるのがこのケース(RDBMSごとに用語は異なる)。 テーブルアクセスが省かれるため、行数が多いクエリで劇的に速くなります。

設計のポイント

  • クエリで参照するカラムだけを覆えばよい。SELECT * ではなく必要な列だけを取る
  • ソートや集約に使うカラムを含めておくと、そのままインデックスから結果が返せる
  • 大きなカラムを覆うとインデックスが膨らむので費用対効果を確認する

よくある疑問

Q.INCLUDE付きインデックスとは?
A.多くのRDBMSに、インデックスキーには使わないが値だけをインデックスに保持するためのオプションがあります。これを使うと、キーとしての探索性能を保ちつつ、カバリング用の追加カラムを持たせられます。
Q.カバリングインデックスは常に得?
A.いいえ。インクルードするカラムが多いほどインデックスサイズが増え、更新コストも上がります。頻出クエリに絞って設計するのが基本です。
Q.実行計画で見分けるには?
A.「Index Only Scan」「Using index」など、RDBMSごとに表現は違いますが、いずれも「テーブル本体を触っていない」ことを示す文言が実行計画に現れます。

関連トピック

もっと学びたい方へ(おすすめ書籍)

おすすめ
達人に学ぶDB設計徹底指南書 第2版
ミック

テーブル設計と正規化、パフォーマンス考慮のインデックス設計まで実務レベルで学べる定番書。第2版ではクラウド対応も強化。

Amazon で見る →
情報処理教科書 データベーススペシャリスト 2025年版
三好康之

IPAデータベーススペシャリスト試験の総合対策書。インデックス関連は本サイトと合わせて学ぶと理解が深まる。

Amazon で見る →
SQL実践入門 ── 高速でわかりやすいクエリの書き方
ミック

「なぜこの書き方が速いのか」を実行計画から説明する一冊。条件分岐・集約・結合・更新のそれぞれで、良い書き方と悪い書き方を対比しながら読める。

Amazon で見る →
おすすめ
楽々ERDレッスン (CodeZine BOOKS)
羽生章洋

ER 図をどう「使える設計」に落とすか、実務の判断まで踏み込んだ入門書。エンティティの切り出しから多対多の扱いまで具体例が豊富。

Amazon で見る →
おすすめ
スッキリわかるSQL入門 第4版 ドリル256問付き!
中山清喬/飯田理恵子

ドリル 256 問を実際に打ちながら進める SQL の入門書。付属のブラウザ環境で演習できるので、SELECT から結合・集約までを環境構築で止まらずに通せる。

Amazon で見る →
達人に学ぶSQL徹底指南書 第2版
ミック

SQLの本質的な使い方と、インデックスが効くクエリの書き方を学べる。ウィンドウ関数など現代SQLも網羅。

Amazon で見る →
SQLアンチパターン 第2版
Bill Karwin

実務でやりがちなSQL・DB設計のアンチパターンとその回避策を体系的に学べる。

Amazon で見る →
[改訂3版]内部構造から学ぶPostgreSQL
勝俣智成 ほか

PostgreSQLの内部構造・ストレージ・インデックス機構を丁寧に解説。設計と運用計画の鉄則が学べる。

Amazon で見る →
理論から学ぶデータベース実践入門
奥野幹也

リレーショナルモデルの理論から、インデックス設計を含む実務で使えるSQLまで解説。

Amazon で見る →

本セクションはAmazonアソシエイトのリンクを含みます。

オンライン個別指導

もっと深くDBを学びたい方へ。

たいてっくが、SQL・データベース設計・パフォーマンスチューニング・IPAデータベーススペシャリスト対策まで、1対1で学習をサポートします。まずは無料相談から。

無料相談を予約する →
受講者の声 (DB・SQL コース)
menta レビュー原文を見る →
  • 教え方も上手で、お人柄も良いメンターです。DB周りの知識はもちろん、何より、しっかり教えてあげようという姿勢がとてもありがたかったです。データベース、SQLの学習を考えている方にはおススメです。
    H 様DB・SQL コース受講
  • 体系的に知識を教えてくださり、実際の業務でも大変役立っております。特に短い時間で効率よく知識の習得や、練習をできているのは期待以上でした。
    M 様DB・SQL コース受講
  • 大変充実したコンテンツでわかりやすいご説明をありがとうございました。基本的な質問にも丁寧にご説明いただき、また業務のご相談にも乗って頂き大変有意義な時間でした。
    K 様DB・SQL コース受講