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

4.5　SELECT の取得データ件数が異なる場合の性能差

キー列（PRIMARY KEY）を利用した検索（SELECT ステートメント）の性能効果に関しては、第2章のポイントカード システムで確認しているので、ここでは単純なテーブルを利用して、取得するデータ件数が異なる場合の SELECT ステートメントの性能効果を確認してみます。次のパターンを確認してみました。

• SELECT の取得件数が約 5件の場合（シングル実行、100万回実行時）
• SELECT の取得件数が約 100件の場合（シングル実行、50万回実行時）
• SELECT の取得件数が約 1万件の場合（シングル実行、500回実行時）

いずれも WHERE 句で「=」演算子で検索を行って、その結果件数が異なる場合の性能を確認してみました。結果は、次のとおりです。

結果は、約5件の結果が返る場合に 1.3倍、約100件の結果が返る場合に 2.19倍、約1万件の結果が返る場合に 2.17倍となり、いずれもディスク ベースよりも性能向上することを確認できました。このように、インメモリ OLTP は、「=」演算子を利用した検索には強いことを確認することができました。また、今回のテストはシングル実行でしたが、インメモリ OLTP では、SELECT ステートメントがロック待ちおよびラッチ待ちになることがないので、多重度が上がって、更新系のステートメントと同時実行される状況では、さらに SELECT ステートメントの性能が向上することになります。

◆ 検証の詳細

この検証の詳細は、次のとおりです。

テストで使用したテーブルには、1,000万件のデータ（ディスク ベースもインメモリ OLTPも同じデータ）を格納して、col1（int）には 1からの連番（IDENTITY）、col2（int）には 0～200万の間の乱数、col3（int）には 0～10万の間の乱数、col4（int）には 0～1,000の間の乱数、col5（datetime）には 2009/01/01 以降の 5年分のデータを分単位（2,628,000通り）で格納（乱数で分ごとに 4～5件のデータが格納）されるようにしています。

このように乱数を利用することで、col2 で検索した場合には約5件、col3 で検索した場合には約100件、col4 で検索した場合には約1万件の結果が返るようになります。

また、col2 で検索する場合には、テーブル構造を次のように変更して、col2 列へインデックスを作成し、Index Seek で検索できるようにしています。

ディスク ベースのテーブルは、従来ながらの b-tree インデックス、インメモリ OLTP では、HASH または bw-tree インデックスを作成して、性能に違いが出るのかも確認してみました。

ネイティブ コンパイル SP は、次のように作成しています。

実際に、ネイティブ コンパイル SP や SQL ステートメントを実行する部分には、.NET（VB.NET と ADO.NET）を利用して、次のようなコードを記述しています。

col2 の検索では、For ループで 100万回繰り返し実行を行って、col2 へ与える値（@p1）には Random クラスで 0～10万の間の乱数を生成したものを利用することで、同じ値での検索にならないようにしています。また、接続（SqlConnection）の Open と Close を入れたり、検索結果を変数へ格納したりすることで、より実際のアプリケーションに近い形の検索になるようにしています。

このコードを実行したときを SQL Server Profiler ツールでキャプチャすると、次のように col2 へ与える値（@p1）に乱数がセットされていることを確認することができます。

また、実行時間の測定には、Stopwatch クラスを利用してします（後述しますが、Stopwatch クラスでは、ミリ秒未満の計測＝マイクロ秒単位での計測をすることができません。今回のように何万回と SQL ステートメントを実行する場合の計測であれば問題ありませんが、単一／1回のステートメントを実行する場合の計測には利用することができません。∵1回のステートメントの実行ではマイクロ秒レベルで完了してしまうため）。

◆ col3 列の検索の場合（約 100件の結果が返る）

col3 で検索した場合には約100件の結果が返るようにしています。

また、col3 で検索する場合には、テーブル構造を次のように変更して、col3 列へインデックスを作成し、Index Seek で検索できるようにしています。

ネイティブ コンパイル SP は、次のように作成しています。

実際に、ネイティブ コンパイル SP や SQL ステートメントを実行する部分は、前述の .NET コードと同じものを利用しています。

◆ col4 列の検索の場合（約 1万件の結果が返る）

col4 で検索した場合には約1万件の結果が返るようにしています。

また、col4 で検索する場合には、テーブル構造を次のように変更して、col4 列へインデックスを作成し、Index Seek で検索できるようにしています。

ネイティブ コンパイル SP は、次のように作成しています。

実際に、ネイティブ コンパイル SP や SQL ステートメントを実行する部分は、前述の .NET コードと同じものを利用しています。

◆ 検証のまとめ ～SELECT の取得データ件数の違い～

検証結果をまとめると、次のようになります。

Native SP Hash では、約5件の結果が返る場合に 1.3倍、約100件の結果が返る場合に 2.19倍、約1万件の結果が返る場合に 2.17倍となり、どれもディスク ベースよりも性能向上することを確認できました。このように、インメモリ OLTP は、「=」演算子を利用した検索には強いことを確認することができました。

検索列に HASH インデックスを利用するか、bw-tree インデックスを利用するかでは、HASH インデックスのほうが若干速い程度で、ほとんど差が出ないことも確認することができました（後述しますが、bw-tree インデックスは、範囲スキャンに強いという特性があります）。

また、PRIMARY KEY に bw-tree インデックスを利用した場合（表の bw bw）と HASH インデックスを利用した場合（表の bw）も、大きな差は出ないことを確認することができました。

また、今回のテストはシングル実行でしたが、インメモリ OLTP では、SELECT ステートメントがロック待ちおよびラッチ待ちになることがないので、多重度が上がって、更新系のステートメントと同時実行される状況では、さらに SELECT ステートメントの性能が向上することになります。

◆ ハッシュ インデックスのチェーンの長さ

BUCKET_COUNT（バケット数）については後述しますが、HASH インデックスでは、十分な BUCKET_COUNT を設定している場合には、同じ値が、同じハッシュ値になって、チェーンが長くなります。

チェーンの長さは、次のように「dm_db_xtp_hash_index_stats」動的管理ビューを利用することで確認することができます。

上の結果は、col2 列に作成した HASH インデックスの場合の結果ですが、col2 列は同じ値が約 5件なので、avg_chain_length（平均のチェーンの長さ）も 5 になっていることを確認できます。

col3 列に作成した HASH インデックス（idx3）の場合は、次のような結果になります。

col3 列は同じ値が約 100件なので、avg_chain_length（平均のチェーンの長さ）も 100 になっていることを確認できます。