SQL Server パフォーマンスチューニング、コンサルティング、アドバイス、相談、定期診断、トレーニング

ホーム＞技術情報＞ SQL Server 2012 自習書 No.12 Analysis Services によるインメモリ BI 入門

SQL Server 2014 実践シリーズ（HTML 版）
「No.1 インメモリ OLTP 機能の実践的な利用方法」

松本美穂と松本崇博が執筆した SQL Server 2014 実践シリーズの「No.1 インメモリ OLTP 機能の実践的な利用方法」の HTML 版です。日本マイクロソフトさんの Web サイトで Word または PDF 形式でダウンロードできますが、今回、HTML 版として公開する許可をいただきましたので、ここに掲載いたします。[2015年12月29日]

目次へ | 前のページへ | 次のページへ

4.7　bw-tree インデックスの選択基準、範囲スキャン

前々項（SELECT の取得件数の違い）と前項（JOIN の性能）では、HASH インデックスでも bw-tree インデックスでも大きな性能差はないということを確認しましたが、大きな差が現れるのが ”範囲スキャン”（Range Scan）の場合です。範囲スキャンは、範囲検索（< や >、BETWEEN などを利用した検索）の場合に内部的に行われるスキャンです。HASH インデックスは範囲スキャンに弱く、bw-tree インデックスは範囲スキャンに強いという特性を持ちます。このため、bw-tree インデックスは Range Index と呼ばれることもあります。

◆ テストで使用したテーブルの構成

範囲スキャンについては、前項で利用した 1,000万件のテーブルの col5 列（datetime 型）を利用して性能を確認してみました。

00265

col5 には、2009/01/01 00:00:00～2014/01/01 00:00:00 までの間の 5年分のデータを分単位（2,628,000通り）で格納（乱数で分ごとに 4～5件のデータが格納）されるようにしています。

col5 で「=」演算子を利用して検索した場合（範囲検索ではない場合）には、次のように 4～5件の結果が返ります。

00266

このように、「=」演算子で日時分を指定する場合には、Index Seek で検索できるように、col5 列にインデックスを作成しています（以下）。

00267

◆ 範囲スキャン～日付の検索～

このテーブルに対して、次のように範囲検索（< や >、BETWEEN などを利用した検索）を行った場合は、ディスクベースの b-tree インデックスでは、Index Seek（範囲スキャン）で完了します。

00268

これに対して、インメモリ OLTP の HASH インデックスを利用している場合は、次のように Table Scan になってしまいます。

00269

HASH インデックスは、範囲検索には弱く、全データをスキャンしなければなりません。

一方、bw-tree インデックスを利用している場合は、次のように Index Seek（範囲スキャン）で取得することができます。

00270

ディスクベースの b-tree インデックスと同様、bw-tree インデックスは範囲検索に強いという特性を持ちます。

◆ 検証結果

範囲スキャンを 5,000回シングル実行したときの実行時間（5,000回を 3回実行して、その平均を取得し、ディスクベースの結果を 100とした相対値に変換したもの）は、次のようになりました。

00271

00272

結果は、HASH インデックスを利用した場合は、桁違いに遅くなることを確認することができました（ネイティブコンパイル SP 利用時は 82倍、SQL 直接実行時は 172倍も遅い）。これに対して、bw-tree インデックスを利用した場合は、ディスクベースよりも約 2.7倍も速い結果になり、大きな性能効果を得られることが分かりました。

このように、範囲検索（< や >、BETWEEN などを利用した検索）を速くしたい場合には bw-tree インデックスが非常にお勧めになります。これに対して、HASH インデックスを利用している場合には、範囲検索（範囲スキャン）が桁違いに遅くなってしまうことを念頭に置いておく必要があります（次項で説明しますが、HASH インデックスはフルスキャンにも弱いという特性を持っていることに注意する必要があります）。

◆ 更新への影響～bw-tree は更新が遅くなる～

bw-tree インデックスは、範囲検索が速くなることが大きなメリットですが、更新（UPDATE、INSERT、DELETE）処理が遅くなってしまうというデメリットもあります。

次のグラフは、第1章で説明した 5,000万件分の INSERT（1件ずつ INSERT を多重実行）を行った場合の結果に、bw-tree の結果を加えたものです。

00273

HASH インデックスよりも、bw-tree インデックスのほうが少し遅いことを確認できると思います。しかし、ディスクベースの結果に比べれば断然速いので、範囲スキャンが HASH インデックスに比べて圧倒的に速いことを考慮すれば、利用価値が高いインデックスと言えます。

bw-tree インデックスが更新に弱いことは、一括 INSERT などで大量データを更新した場合に、顕著な性能差を確認することができます。これは次のような状況です。

00274

このように、INSERT .. SELECT を利用して、1,000万件のデータを丸ごと INSERT したときの実行時間を比較すると、次のグラフのようになります。

00275

このテストで利用したテーブルは、col2 の検索（取得件数が約 5件になる検証）で利用したときと同じもので、次のようになっています。

00276

このように、bw-tree インデックスは、HASH インデックスよりも更新（UPDATE、INSERT、DELETE）処理が遅くなってしまうというデメリットがあるので、それを覚えておく必要があります。もちろん、bw-tree インデックスには、範囲スキャン（範囲検索）に強い（ディスクベースよりも範囲スキャンが速い）という大きなメリットもあるので、それとのトレードオフで利用することになります。