現在、複雑なフェッチを実行しているストアドプロシージャがあり、使用するとタイムアウトになることがよくあります。私の部門で提案された解決策は、単にタイムアウト時間の長さを増やすことでした。本当にやりたくないです。このsprocをリファクタリングしたいのですが、非常に複雑で文書化されていないため（レガシーシステム）、リファクタリングによって同じ機能がより効率的に実行されないのではないかと心配しています。同じ関数がより短い時間で実行されることを保証するためにストアドプロシージャをリファクタリングするときに使用する戦略はありますか？
これは、Microsoft SQLServer2005のストアドプロシージャです。
通常、タイムアウトは単一の SQL ステートメントで発生します。おそらく一時テーブルを効果的に使用して、proc を個別のステートメントに分割し、1 つのチャンクで多くのことを実行しようとしないようにします。これを行うことで、パフォーマンスのボトルネックに焦点を合わせ、必要に応じていくつかの有用なインデックスを特定することもできます.
私は過去にこのような状況に直面したことがあります。最善の方法は、単純な C# または VB .Net アプリケーションを作成することです。sp をリファクタリングするときは、新しい名前を付けます。アプリケーションを使用して、古い SP と新しい SP の両方を呼び出します。次に、2 つの sp の出力を比較して、まったく同じ値が同じ順序で返されることを確認します。
リファクタリングによってビジネス ロジックが変更されていないことを確認するために、できるだけさまざまな入力パラメーターをテストする必要があります。
また、NUnit を使用すると、このタスクを簡素化できます。
現在の職に就いたとき、新しいスキーマ用に変更しなければならないデータベースが与えられました。100個以上のSPを変更する必要がありました。説明したアプリケーションを使用して、変更の 1 つがビジネス ルールに違反していないことを合理的に確信することができました。
そうです、タイムアウトを増やすだけでは最初の答えが間違っています。できる限り SP を改善し、必要に応じてタイムアウトを増やします。
私が遭遇した非効率的なストアド プロシージャの最も一般的な原因は、セット ベースの操作ではなく、スカラー型の操作が普及していることです。ほとんどの RDBMS システム (Oracle、SQL Server、MySQL など) は、複数回繰り返される単一の操作ではなく、大量のデータ セットで作業を実行する際にはるかに効率的です。各行に対して 100 万回操作を実行するよりも、100 万行のデータに対して 1 つの操作を実行する方が効率的です。
これらのタイプのボトルネックを特定しようとした後 (通常は、最初に関数呼び出しを確認します)、参照しているテーブルのインデックス作成戦略を検討することをお勧めします。選択した RDBMS によっては、サンプル ワークロードに基づいて適切なインデックス構造を検出するのに役立つウィザード タイプの機能がいくつかある場合があります。
どのデータベースを使用していますか? それは私の提案のいくつかを微調整するのに役立つかもしれません.
SQL Server プロファイラーを使用して、現在の SP がどのように実行されているかを調査します。非効率性を浮き彫りにし、最初から特定の領域だけをターゲットにして、よりパフォーマンスの高い部分はそのままにしておくことができます。その後、修正した SP で再びプロファイラーを使用して、パフォーマンスを比較できます。
関数呼び出しをよく見るという Gunny の推奨事項に同意します。セットベースの操作では、これらはパフォーマンスに実際の影響を与える可能性があります。過去に、単一の UDF を取り除き、ロジックをインラインで複製するだけで、大幅なパフォーマンスの向上を達成しました。