次の方法で共有


ネイティブ コンパイル ストアド プロシージャの呼び出しに関するベスト プラクティス

ネイティブ コンパイル ストアド プロシージャの特徴:

  • 通常、アプリケーションのパフォーマンスが重要な部分に使用されます。

  • 頻繁に実行されます。

  • 非常に高速であることが求められます。

ネイティブ コンパイル ストアド プロシージャを使用することに伴うパフォーマンス上の利点は、プロシージャによって処理される行の数と論理の量に従って大きくなります。 たとえば、次の 1 つ以上を使用している場合は、ネイティブ コンパイル ストアド プロシージャのパフォーマンスが向上します。

  • 集計。

  • 入れ子になっているループ結合。

  • 複数ステートメントの SELECT、INSERT、UPDATE、および DELETE 操作。

  • 複合式。

  • 条件ステートメントとループなど、手続き型のロジック。

単一行のみを処理する必要がある場合は、ネイティブ コンパイル ストアド プロシージャを使用しても、パフォーマンス上の利点が得られるとは限りません。

サーバーによるパラメーター名のマップと型の変換を回避するには:

  • プロシージャに渡されるパラメーターの型をプロシージャ定義の型に一致させます。

  • ネイティブ コンパイル ストアド プロシージャを呼び出すときに序数 (名前のない) パラメーターを使用します。 最も効率的に実行するには、名前付きパラメーターを使用しないでください。

ネイティブ コンパイル ストアド プロシージャでの (非効率的な) 名前付きパラメーターの使用は、XEvent の hekaton_slow_parameter_passingreason=named_parameters と共に使用して検出できます。

同様に、同じ XEvent hekaton_slow_parameter_passingreason=parameter_conversion と共に使用して、一致しない型の使用を検出することができます。

メモリ最適化テーブルを使用する場合は再試行ロジックを実装する必要があるため (多くのシナリオで)、特定の機能の制限を回避する必要があるため、ラッパー解釈 Transact-SQL ストアド プロシージャを作成することをお勧めします。 例については、「 Memory-Optimized テーブルでのトランザクションの再試行ロジックのガイドライン」を参照してください。

参照

ネイティブ コンパイル ストアド プロシージャ