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

ホーム＞技術情報＞ SQL Server 2014 実践 No.1 インメモリ OLTP 機能の実践的な利用方法

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

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

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

2.5　SELECT ステートメントの具体的な性能向上例

次に、残りの SQL ステートメントの具体的な内容について説明します。各ステートメントをシングル実行したときの実行時間と性能向上率の詳細は、次のとおりです。

00101

ネイティブコンパイル SP を利用することで、全体として 1.74倍の性能向上（42.5% の向上）を実現できています。

◆ SELECT ステートメントは 1.6～1.9倍の性能向上～PKを利用した参照～

SELECT ステートメントに関しては、顧客マスターやカードマスター、メッセージマスター、カード種別マスターの参照など、マスター系テーブルの参照で、すべてキー値（PRIMARY KEY）が含まれている検索を行っています。これらは、ネイティブコンパイル SP 化することで、38～46%の性能向上（1.6～1.9倍の性能向上）を実現できることが分かりました。それぞれの PRIMARY KEY やデータ型は、次のとおりです。

00102

カードマスターの「カードID」やメッセージマスターの「MessageID」列などは、数値データのみですが、char データ型で定義されています（char データ型の ID列やコード列を利用されているという方は多いのではないでしょうか？弊社のお客様にもたくさんいらっしゃいます）。

◆ カードマスターの検索例

カードマスターの検索は、次のように行っています。

SELECT col1, col2, col3, col4, …（32列分の列が列挙されています）
FROM カードマスター
WHERE カードID = @p1 AND 企業コード = @p2

WHERE 句の検索条件には、「カードID」と「企業コード」の 2つの列がありますが、カードID 列が PRIMARY KEY で、この列にはハッシュインデックスを作成しているので、Index Seekで検索することができています。この検索は、ネイティブコンパイル SP 化することで、1.8倍の性能向上を確認しています。

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

CREATE PROC p_カードマスター検索
@p1 nchar(16), @p2 nchar(10)
WITH NATIVE_COMPILATION, EXECUTE AS OWNER, SCHEMABINDING
AS
BEGIN ATOMIC
WITH ( TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'japanese' )
  SELECT col1, col2, col3, col4, …（32列分の列が列挙されています）
   FROM dbo.カードマスター
    WHERE カードID = @p1 AND 企業コード = @p2
END

NATIVE_COMPILATION や BEGIN ATOMIC など、新しいキーワードがいくつかありますが、ネイティブコンパイル SP を作成するのは、それほど難しいことではないのがお分かりいただけるのではないでしょうか。これを作成するだけで、シングル実行で 1.8倍の性能向上を実現できるわけですから、インメモリ OLTP 機能のスゴさを体感することができました。

◆ メッセージマスターの検索例

メッセージマスターの検索は、次のように行っています。

SELECT MessageID, col2, col3, col4, …（8列分の列が列挙されています）
FROM メッセージマスター
WHERE MessageID = @p1

メッセージマスターは、「MessageID」列が PRIMARY KEY で、この列にはハッシュインデックスを作成しているので、Index Seekで検索することができています。この検索は、ネイティブコンパイル SP 化することで、1.6倍の性能向上を確認することができました。

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

CREATE PROC p_メッセージマスター検索
@p1 nchar(10)
WITH NATIVE_COMPILATION, EXECUTE AS OWNER, SCHEMABINDING
AS
BEGIN ATOMIC
WITH ( TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'japanese' )
SELECT MessageID, col2, col3, col4, …（8列分の列が列挙されています）
FROM dbo.メッセージマスター WHERE MessageID = @p1
END

カードマスターの検索のときとほとんど同じ形のネイティブコンパイル SP であることがお分かりいただけるのではないでしょうか。

◆ カード種別マスターの検索例

カード種別マスターの検索は、次のように行っています。

SELECT col1, col2, col3, col4, …（24列分の列が列挙されています）
FROM カード種別マスター
WHERE カードID = @p1 AND 種別ID = @p2

カード種別マスターは、(カードID, 種別ID) の 2つの列で構成される複合主キー（PRIMARY KEY）で、この列にはハッシュインデックスを作成しているので、Index Seekで検索することができています。この検索は、ネイティブコンパイル SP 化することで、1.7倍の性能向上を確認することができました。

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

CREATE PROC p_カード種別マスター検索
@p1 nchar(16), @p2 int
WITH NATIVE_COMPILATION, EXECUTE AS OWNER, SCHEMABINDING
AS
BEGIN ATOMIC
WITH ( TRANSACTION ISOLATION LEVEL = SNAPSHOT, LANGUAGE = N'japanese' )
  SELECT col1, col2, col3, col4, …（24列分の列が列挙されています）
   FROM dbo.カード種別マスター
    WHERE カードID = @p1 AND 種別ID = @p2
END

◆ 顧客マスターの検索例（IN／UNION ALL をメモリ最適化テーブル変数へ）

顧客マスターは、前の項で IN 演算子を UNION ALL へ変更したものでした。しかし、ネイティブコンパイル SP 内では、IN 演算子や OR 演算子、UNION ALL が利用できない、という制限があるので、これを回避するために、「メモリ最適化テーブル変数」を利用しています。これについては、次の項で説明します。

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