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.7　UPDATE ステートメントの具体的な性能向上例

UPDATE ステートメントは、「顧客マスター」と「カードマスター」に対する更新があります。

00104

◆ UPDATE ステートメントは 1.2～1.3倍の性能向上～PKを利用した更新～

顧客マスターとカードマスターに対する更新は、どちらもキー値（PRIMARY KEY）を利用した更新を行っていて、これらは、ネイティブコンパイル SP 化することで、15～20%の性能向上（1.2～1.3倍の性能向上）を実現できることが分かりました。

顧客マスターとカードマスターは、SCHEMA_AND_DATA（データの永続化有り）に設定しており、ログへの書き込みがある分、SELECT ステートメントほどの性能向上とはなりませんでしたが、ネイティブコンパイル SP を作成することの重要性を感じることができました（作成しない場合は、0.6～3.3％の性能向上のみでした）。

◆ 顧客マスターの更新

顧客マスターの更新は、次のように行っています。

UPDATE 顧客マスター
SET col3 = @p3, col4 = @p4, col5 = @p5, col6 = @p6, col7 = @p7
WHERE カードID = @p1 AND カード種別 = @p2

WHERE 句の検索条件に、複合主キー（PRIMARY KEY）である「カードID」と「カード種別」を指定して、その他の列を更新しています。この更新は、ネイティブコンパイル SP 化することで、1.2倍の性能向上を確認することができました。

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

CREATE PROC p_顧客マスター更新
@p1 nchar(16), @p2 nvarchar(2),
@p3 datetime, @p4 int, @p5 datetime, @p6 datetime, @p7 nchar(1)
WITH
   NATIVE_COMPILATION, EXECUTE AS OWNER, SCHEMABINDING
AS
BEGIN ATOMIC
WITH ( TRANSACTION ISOLATION LEVEL = SNAPSHOT,
        LANGUAGE = N'japanese')
  UPDATE dbo.顧客マスター
   SET col3 = @p3, col4 = @p4, col5 = @p5, col6 = @p6, col7 = @p7
    WHERE カードID = @p1 AND カード種別 = @p2
END
go

こうした単純な UPDATE を行うステートメントでも、ネイティブコンパイル SP を作成するだけで、シングル実行で 1.2倍の性能向上を実現できるわけですから、インメモリ OLTP 機能はやはり便利です。

◆ カードマスターの更新

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

UPDATE カードマスター
SET col2 = @p2, col3 = @p3, col4 = @p4, …（31列分の更新が列挙されています）
WHERE カードID = @p1

WHERE 句の検索条件に、PRIMARY KEY である「カードID」列を指定して、その他の列を更新しています。この更新は、ネイティブコンパイル SP 化することで、1.3倍の性能向上を確認することができました。

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

CREATE PROC p_カードマスター更新
@p1 nchar(16), @p2 データ型, @p2 データ型, …（32列分のパラメーター）
WITH
   NATIVE_COMPILATION, EXECUTE AS OWNER, SCHEMABINDING
AS
BEGIN ATOMIC
WITH ( TRANSACTION ISOLATION LEVEL = SNAPSHOT,
        LANGUAGE = N'japanese')
  UPDATE dbo.カードマスター
   SET col2 = @p2, col3 = @p3, col4 = @p4, …（31列分の更新が列挙されています）
    WHERE カードID = @p1
END
go

Tips：全列の更新は必要？？
上記のカードマスターの更新のように、PRIMARY KEY を指定して、残りの列をすべて更新する（32列中、キーを除いた 31列を更新する）、という処理を行っているユーザーは多いのではないでしょうか？
特に、データアクセスのためのフレームワークなどを利用していると、自動的にこのような更新を行う（特に更新が必要がない列まで含めて、全ての列を更新してしまう）場合が多々あり、これでは余計なオーバーヘッドがかかってしまいます（ログの書き込み量も増えてしまいます）。
そういう利用方法をされているお客様は、弊社にもたくさんいらっしゃいました。これを必要な列のみの更新へ変更することができれば、さらなる性能向上を実現することができます...

Tips：主キー列まで更新してしまう？は NG！
利用しているフレームワークによっては、主キー（PRIMARY KEY）列まで更新してしまうという場合もあると思います（弊社のお客様にもいらっしゃいました）。これは、次のような状況です。

UPDATE dbo.カードマスター
SET カードID = @p1, col2 = @p2, col3 = @p3, …（すべての列の更新）
WHERE カードID = @p1

カードマスターの PRIMARY KEY である「カードID」を WHERE 句の検索条件に入れているにも関わらず、カードID 列まで更新してしまっています。カードID であれば、更新されることはあり得ない（更新が必要な場合は、番号の変更でなく、新しいカードを発行して、新しいカードID を割り当てる）、という運用をしていることが多いのではないでしょうか？このように、主キー列は、本来更新される可能性がほとんどないにも関わらず、フレームワークが全ての列を更新するようになっていて、この形式で更新をしているという場合があります。
しかし、メモリ最適化テーブルでは、PRIMARY KEY 列の更新がサポートされていないので、このような更新を行った場合は、エラーとなってしまいます。
00105