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

2.18　ネイティブ コンパイル SP を利用するときのポイント

この章の後半では、ネイティブ コンパイル SP を利用するにあたってのポイントを説明してきましたが、これらをまとめると、次のようになります。

• 今回のポイントカード システムでは、ネイティブ コンパイル SP を作成することで、シングル実行で 1.2～4.6倍の性能向上を確認。
  PRIMARY KEY 列を利用した SELECT ステートメントは 1.6～1.9倍の性能向上、
  PRIMARY KEY 列を利用した UPDATE ステートメントは 1.2～1.3倍の性能向上、
  単純な INSERT ステートメントは 1.4倍の性能向上、
  Delayed Durability（遅延書き込み）を利用することで、4.6倍の性能向上を確認
• アプリケーションから実行される SQL を SQL Server Profiler でキャプチャすることで、簡単にネイティブ コンパイル SP を作成できる
• ADO.NETであれば、ネイティブ コンパイル SP を実行するための修正は、わずか2行
• ネイティブ コンパイル SP の実行方法の違い（SqlCommand の CommandType の指定や、文字列連結実行）で、性能差が出るので注意する。CommandType には CommandType.StoredProcedure を指定し、SqlParameter を利用するのが最速
• ネイティブ コンパイル SP 内では、オブジェクト名にスキーマ名を付与する必要がある（dbo.テーブル名 形式で記述する）
• SELECT * が利用できないので、列名を列挙する必要がある
• データベースの照合順序が Japanese_CI_AS の場合は、ネイティブ コンパイル SP 内の単一引用符（文字リテラル）には、Nプレフィックスを付ける必要がある
• データベースの照合順序に Japanese_CI_AS を利用して、列のデータ型に char／varchar を利用している場合は、ネイティブ コンパイル SP のパラメーターに char／varchar を利用することができないので、直接 SQL を実行する方法を利用せざるを得ない（これだと、ネイティブ コンパイル SP を利用するよりも約 1.4倍遅い）
• データベースの照合順序に Latin_～ など、コードページ 1252 を利用している場合は、列のデータ型に char／varchar を利用したとき、ネイティブ コンパイル SP のパラメーターにも char／varchar を利用すること（型を合わせること）が重要になる（型が合わない場合は、暗黙の型変換によって、性能が桁違いに遅くなる）。
  列のデータ型に char／varchar を利用する場合は、日本語データが格納できなくなる（格納するには nchar／nvarchar を利用する必要がある）
• ADO.NET の AddWithValue は、nvarchar(X) に自動変換されるので、暗黙の型変換が発生しないように注意する。char／varchar を利用するには、SqlParameter でデータ型を明示指定する（SqlDbType.Char などを利用する）ようにする
• JDBC の prepareStatement の SetString は、既定で nvarchar(4000) に自動変換されるので、暗黙の型変換が発生しないように注意する。varchar(8000) に自動変換されるようにするには、sendStringParametersAsUnicodeを falseへ設定する
• できる限り、小さいデータ型を利用することで、メモリ使用量を削減することができる。
  英数字データのみなら nchar よりも char、
  数値のみのデータなら char よりも int や bigint、decimal、
  フラグ列なら char(1) よりも bit を利用するなど
• メモリ使用量は、dm_db_xtp_table_memory_stats 動的管理ビューで確認できる
• ADO.NET の ExecuteNonQuery は、結果件数を取得できなくなることに注意する
• SCOPE_IDENTITY や @@ROWCOUNT を別バッチから取得している場合は、ネイティブ コンパイル SP 内へ含めるようにする
• メモリ最適化テーブルでは、PRIMARY KEY 制約やインデックスを付与する文字データ列に、BIN2 照合順序が必須になる（Japanese_BIN2 などを利用）
• ネイティブ コンパイル SP 内での文字データの比較演算（=）や並べ替え（ORDER BY）を行うには BIN2 照合順序が必須になる。BIN2 照合順序の場合は、大文字と小文字を区別することに注意する。
  大文字と小文字を区別しないように検索したい場合は、データの格納時に大文字または小文字に統一して格納するようにすると良い
• ネイティブ コンパイル SP での更新競合は、TRY .. CATCH で再試行ロジックを記述することで対応する
• 実際の実行プランが確認できなくなるので、推定実行プランを利用するようにする