ビットマップインデックス

値の有無をビット列で表すインデックス。性別や区分のように取り得る値の種類が少ない列に有効で、複数条件の絞り込みを論理演算で高速に処理できる。更新の多い表には向かない。

列が取り得る値ごとに、各行がその値を持つかどうかを1ビットで表したビット列を持つインデックス。性別や地域のように値の種類が少ない列に向き、複数の条件の組合せをビット列の論理演算で高速に絞り込める。更新のたびにビット列を書き換えるので、更新の多い表には向かない。

各キー値に対してビットマップ（ビット列）を持つインデックス。カーディナリティが低い列（性別、都道府県など）の検索や、複数条件のAND/OR検索に効率的。データウェアハウスでよく使用される。

表のデータを行単位ではなく列単位にまとめて格納するデータベース。集計に必要な列だけを読めばよく、同じ列には似た値が並ぶため圧縮率も高いので、大量の行を対象にした分析処理（OLAP）に向く。1行ずつの挿入や更新は行指向より不利で、データウェアハウス向けの製品やクラウドのDWHサービスに多く採用されている。

表の行を、特定の列の値をもとに速く探し出すために作る補助的なデータ構造。インデックスとも呼び、B木、ハッシュ、ビットマップなどの方式がある。検索や結合は速くなるが、行の追加・更新・削除のたびに索引も更新するので更新処理が遅くなり、記憶領域も要るため、検索条件や結合条件によく使われ絞込みの効く列に絞って設定し、索引の数を増やしすぎないようにする。

検索性能を上げるために、正規化した表をあえて統合したり、導出項目や他の表の項目を重複して持たせたりすること。結合の回数を減らせるので参照が速くなるが、同じデータを複数箇所で更新する必要が生じ、整合性を保つ仕組み（トリガや更新手順）が別に要る。参照が中心のデータウェアハウスのスタースキーマなどで使われる。

問合せで必要な列をすべて含んでいる索引。検索条件の列だけでなく、選択リストや並び替えに使う列も索引に持たせることで、表本体を読まずに索引だけで結果を返せる（インデックスオンリースキャン）。表へのアクセスが省けて入出力が減るが、索引が大きくなり更新の負荷が増える。

キーの値が重複しないことを保証する索引。重複する値の行を追加・更新しようとするとエラーになる。主キー制約や一意性制約を定義すると、多くのDBMSは一意性の検査のためにユニークインデックスを自動で作成する。

表の行そのものを、索引のキーの順に物理的に並べて格納する索引。行の並びは1通りしかないので、1つの表に1つしか作れない。キーの範囲を指定した検索や並び替えでは連続したページを読めばよいので速いが、キーの途中への挿入や更新では行の移動が起きやすい。