ほとんどの主要なデータベースと同じように、SQL Serverはクラスタインデックスを持っているときは、テーブルをB木で保持する。それ以外の場合はヒープを使う。この2つの方法は行に基づいて行われる。この場合、ページ当たりの行数は行全体のサイズに依存する。しかし、SQL Server 2011からはもう一つの選択肢が利用できる。“カラムストアインデックス”を利用することで、SQL Serverは行の代わりに列を元にデータを保存する。
Microsoftの発表では、14億4千万の行を保持する1TBのテーブルを利用するとき、列指向の問い合わせを実行すると、CPU時間で16倍のスピード改善と455倍もの経過時間の改善が見られたということだ。実質的には501秒かかっていた問い合わせが1.1秒までに改善するということだ。このテストは256GBのメモリと32の論理プロセッサを持ったマシンで実施された。
この劇的な改善は各列をそれぞれのページに分離することで実現されている。問い合わせが実行されると結果セットの列だけがディスクからロードされる。対象以外の列が含まれるページは単に無視される。
あらゆる列の組み合わせのカバリングインデックスを保持することと似ている。しかし、この方法だとハードディスクを大量に利用する必要はない。容量は従来のテーブルよりも少なくて済む。SQL Serverのデータ圧縮はページレベルで発生する。また、行よりも列の方がデータが重複している可能性が高い。したがって、カラムストアインデックスを使ったテーブルは高い圧縮率が期待できる。
しかし、カラムストアインデックスを使うかどうかは簡単に決定できない。何よりもまず更新ができない。一度カラムストアインデックスを作成すると、テーブルに対して追加、更新、削除ができなくなる。Microsoftは、毎日の更新作業や読み取り専用データで利用されることをが想定している。更新作業ではインデックスをドロップし、データを更新して、インデックスを再作成するという使い方になる。これは大変な作業になるので、データの変動を論理テーブルの一部分の中だけに抑えるため垂直のパーティショニングをすることもできる。
また、カラムストアインデックスを使うことで性能が劣化する可能性もある。ほとんどの列を扱うような問い合わせをすると行の再結合に膨大な時間がかかるからだ。つまり、OLTPのような問い合わせはOLTPであるがゆえに利用に適さない。言い換えれば、“SELECT *”やひとつの行のすべての値を一度に取り出すような問い合わせをしているなら利用には適さない。