5.1インデックス設計

データベース設計者にとって「インデックスは多いほど良い」という単純な話ではありません。検索を速くする一方で、行の追加・更新・削除のたびにインデックス自体も維持されるため、参照と更新の両方の負荷を見積もったうえで、どの列に・どの種類のインデックスを・どの順序で張るかを判断する必要があります。この節ではインデックス構造の特性と、遅いクエリを改善するための設計判断を学びます。

5.1.1B木インデックスの仕組みと適性

• B木インデックス（B-treeインデックス）＝キー値を大小関係を保ったまま木構造に整理し、根から葉へたどることで対象行をO(log n)程度で見つけられる、最も汎用的なインデックス構造。多くのRDBMSで既定のインデックス種別になっている。
• 木構造で大小関係を保持しているため、等価検索（=）だけでなく範囲検索（>・<・BETWEEN）や並べ替え（ORDER BY）にも強い。日付範囲での抽出や連番の前方一致検索など、業務クエリの大半はB木で十分に高速化できる。

5.1.2ハッシュインデックスとビットマップインデックス

• ハッシュインデックス＝キー値をハッシュ関数で変換し、ハッシュ値をもとに格納位置へ直接アクセスする構造。等価検索（=）はO(1)に近い速度で行えるが、ハッシュ値は大小関係を保たないため範囲検索や並べ替えには使えない。完全一致の検索が支配的で範囲検索がほぼ発生しない列（例：セッションIDでの一意検索）に向く。
• ビットマップインデックス＝列が取りうる値ごとに、各行が該当するかを0/1のビット列で表現する構造。「性別」「会員ランク」のように取りうる値の種類が少ない（低選択性）列では、ビット列同士のAND/OR演算で複数条件を高速に絞り込める。一方、値の種類が多い（高選択性）列や更新頻度が高いテーブルでは、更新のたびにビット列を書き換えるコストが大きく不向き。