SQL では、While ループ、再帰ストアド プロシージャ、カーソルのどれが速いですか? 質問する

SQL Server を使用していると想定します。

まず、誰かが声明で述べたように、再帰ストアドプロシージャは可能ではありますが、スタックサイズの問題でSQL Serverでは良い考えではありません。したがって、深く再帰したロジックは壊れます。ただし、せいぜい2～3レベルのネストであれば、再帰を使用するか、熱膨張係数これも少し再帰的です (SQL Server 2005 以降)。CTE について理解できれば、これは非常に便利な手法です。測定はしていませんが、CTE を使用したいくつかの場所でパフォーマンスの問題が発生したことはありません。

一方、カーソルはパフォーマンスをかなり消費するので、（そしてインターネットの半分) は、頻繁に呼び出されるコードではカーソルを使用しないことを推奨します。しかし、カーソルはforeachC# の に似た、より古典的なプログラミング構造であるため、複雑な複数の内部選択 SQL の怪物よりも、データ操作にカーソルを使用する SQL コードを調べ、理解し、保守する方が簡単だと考える人もいます。そのため、たまに呼び出されるコードでカーソルを使用することは、悪い考えではありません。

といえばwhile、プログラミングの考え方もセットベースからプロシージャベースに移行するため、比較的高速で多くのリソースを消費しない一方で、データベース自体に発行するデータ操作ステートメントの数が大幅に増加する可能性があります。

要約すると、パフォーマンスが最も重要となる複雑なストアド プロシージャを作成する必要がある場合、次のことを試します。

1. セットベースのアプローチを使用する（内部選択、結合、結合など）
2. CTE の使用 (経験豊富なユーザーにとっては明確で扱いやすいが、初心者にとっては少し怪しい)
3. 制御フローステートメント (if、while...) の使用
4. カーソルの使用（手続き型コード、わかりやすい）

その順番で。

コードの使用頻度がはるかに低い場合は、おそらく 3 と 4 を 1 と 2 の前に移動することになるでしょうが、これもまた、多数のテーブルと多数のリレーションを使用する複雑なシナリオの場合のみです。もちろん、結果は人それぞれです。そのため、実際のシナリオで作成した手順をテストして、実際にパフォーマンスを測定します。これは高速であれは低速だといくらでも語ることができますが、実際の測定値を取得するまで、変更によって状況が改善されたのか悪化したのかを判断する方法はありません。

また、忘れてはならないのは、コードの速度はデータと同じだけであるということです。適切なインデックスに代わるものはありません。