カーソルは本当にどれくらい遅く、より良い選択肢になるでしょうか？

Question

私はカーソルがかなりslowであることを読んでいました。私はストアドプロシージャを最適化しようとしており、そのうちの1つはカーソルを使用します。頻繁に私のアプリケーションから呼び出され、多くのユーザー（20000）と行が更新されます。私は別のものとして別のものを使うべきかもしれないと思っていた。

私がやろうとしているのは、レコードのリストを取得し、各行の値に応じて操作することです。だから、例えばのために、私たちは言うてきた -

Employee - Id,Name,BenefitId,StartDate,EndDate 

をそうbenefitIdに基づいて、私は開始日と終了日と更新従業員の詳細の間の日付を使用して、異なる計算を行う必要があります。私はちょうど私の状況についてのアイデアを与えるために、この人為的な例を作っています。

あなたの考えは？一時テーブルやユーザー定義関数を使用するようなカーソルの方がよいでしょうか？あなたはいつそれらを選ぶべきですか？あるいは、カーソルを使用するべきではありませんか？皆さん、ありがとうございました。

Answer 1

私はカーソルを変更し、分未満に処理時間の24時間以上から移動してきました。

これを読んで、あなたはセットベースのロジックを使用してPROCを修正する方法を見て助けるために：あなたが保存されprocsの中でいくつかのビジネス・ロジックをミックスしようとしているように http://wiki.lessthandot.com/index.php/Cursors_and_How_to_Avoid_Them

Answer 2

私はかつてストアドプロシージャをカーソルからセットベースのロジックに変更しました。実行時間は8時間から22秒になりました。それは私たちが話している種類の違いです。

一度に異なるアクションを実行する代わりに、データに対して複数のパスを使用します。更新し、field1 = A、field2がXの場合は、field1 = B、field2がYのように更新および設定してください。

Answer 3

カーソルは行ごとに処理されます。ジェフ・モデン。

これは、RBARとは対照的に、セットベースのSQLプログラミングを行う方法のちょうどone exampleですが、最終的にはカーソルが何をしているかによって異なります。

はまた、StackOverflowの上でこの見て：

RBAR vs. Set based programming for SQL

Answer 4

まずオフ、それが聞こえます。それは一般的にあなたが避けたいものです。よりよい解決策は、そのビジネスロジックをカプセル化する中間層レイヤーを持つことです。そうすれば、データ層は純粋にデータのままです。

元の質問に答えるには、実際にカーソルを使用しているかどうかによって異なります。場合によっては、表変数または一時表を使用できます。可能であれば、テーブル変数を使用することをお勧めしますので、一時テーブルを解放することを覚えておく必要があります。ただし、カーソルを使用する方法はありません。たぶん元のDBAが十分に正規化していない（または正規化しすぎている）かもしれませんし、カーソルを使用して外部キー関係なしで複数のテーブルを通過しなければならないかもしれません。