ストアド プロシージャを設計するときは、セット ベースの操作の方がカーソル ベースの操作よりも優れていると聞いています。
誰かがこれがなぜなのかを簡潔に説明できますか?
ストアド プロシージャを設計するときは、セット ベースの操作の方がカーソル ベースの操作よりも優れていると聞いています。
誰かがこれがなぜなのかを簡潔に説明できますか?
私が管理できる限り簡潔に:
リレーショナル データベース エンジンでは、これらのエンジンがセットベースの操作を実行するように最適化されているため、すべての操作 (ストアド プロシージャ内であるかどうかに関係なく) は通常、セットベースのロジックを使用してより適切にスケーリングされます。
一般に、エンジン内の単一のアトミック操作には、1 行または 1,000,000 行に影響するかどうかにかかわらず、一定のリソース コストがかかります (かなり高くなる場合があります)。
データベース エンジンはアトミック操作のコストに加えてカーソルの状態を維持する必要があるため、カーソルのコストはさらに高くなります。
*手続き型ロジックがセットベースよりも優れたパフォーマンスを発揮する、いくつかのエッジケース/問題のクラス (正確には RDBMS に依存します) があります。
すべて(またはほとんどすべて)のRDMSは、行ベースではなく、セットベースの操作用に最適化されています。ほとんどの場合、セットベースのソリューションは行ベースを上回ります。たとえば、SELECT * FROM table1
カーソルで同じことを行うよりも何倍も高速に実行されます。ただし、カーソルソリューションのパフォーマンスが向上する場合があります。たとえば、一部のRDMS(つまり、SQLServer 2005)でセットベースのアプローチを使用して実行中の集計を計算するには、データを数回再スキャンする必要がありますが、カーソルベースでは1回だけ再スキャンします。
カーソルを使用する必要があるもう1つのケースは、アプリケーションのビジネスロジックで、各行を個別に処理する必要がある場合です。