SQL Server ストアド プロシージャで Try Catch ブロックを使用すると、多くのサーバー リソースが消費される可能性があることを読みました。私の質問は、それがどれだけのリソースを使用するかです。
私は現在、sproc が大量のデータを変更するたびに Try Catch ブロックとトランザクションを使用しています。これは、誤ったデータがデータベースに入力されるのを防ぎ、エラーをログに記録するのに最適ですが、この方法を使用したいと思います。私のすべてのsprocでのプログラミングの。
どのくらいの違いがありますか？
ゼロ。TRY/CATCH を使用するコードは、TRY/CATCH を使用しないコードとまったく同じリソースを消費します。唯一の違いは、通常、前者が後者よりも正確であることです。実際、TRY/CATCH コードは、コード フローが直接 catch ブロックにジャンプし、最後にロールバックするためだけに要求/ストアド プロシージャ内の残りのステートメントを実行することを回避するため、エラーが存在する場合により効率的です。
念のために言っておきますが、私は、各ステートメントの後に @@ERROR をチェックするコードを作成することが、実行可能な代替手段であるとは考えていません。
大学生の頃に本で読んだ
確かに、読み取りは TRY/CATCH を使用した T-SQL コードを参照していませんでしたが、代わりに (JVM または IL の) 例外の有無にかかわらず C++ コードを参照していました。暗黒時代にさかのぼると、例外処理コードを追加するとパフォーマンスに影響があるかどうか (はい、影響があります) と、これを要因と見なすべきかどうか (いいえ、すべきではありません。正しさによる戦い）。しかし、この議論はあなたの観点からはまったく役に立ちません。T-SQL を実行するバックエンド エンジンは、例外処理を使用してコンパイルされており、それに対してできることは何もありません。この場合も、T-SQL コードへの影響はありません。