0

私のシステムには、大量のデータとエクスポート プロセスを処理するので、ある程度は予想されるように、すでに実行時間の長いストアド プロシージャがあります。引数のために、プロシージャはそれ自体で約 10 秒実行されます。このプロシージャが同じパラメータで連続して呼び出されることがあります。

コール 1 - 開始 12:00:10; 持続時間 30 秒

コール 2 - 開始 12:00:15; 持続時間 10 秒

最初の呼び出しは、終了する前に 2 番目の呼び出しが完了するのを待っているようです。プロセス レポートの実行をブロックしましたが、プロファイラーからヒットがありません。また、sys.dm_exec_requests を確認すると、SPID が相互にブロックされていることがわかりません。また、最長の wait_type は async_network_io です。

ストアド プロシージャは、#temp テーブルと @temp テーブルの両方を使用します。これを制御するには、他に何を確認または変更する必要がありますか?

4

1 に答える 1

1

"最長の wait_type は" です。これは、大きなテーブルや幅の広いテーブルなどasync_network_io、転送するデータが多すぎることの症状であることがよくあります。SELECT *

コメントに応じて更新します。

「はい、このプロシージャには並べ替えという二重の機能があります。1) ページ 1 から 20 行を返します。2) これを並べ替えのデータ ダンプに変換する内部ロジックがあります。ここですべてのクライアント データが返されます。

パラメータ スニッフィングと不適切なキャッシュ クエリ プランの影響を受けているようです。プロシージャを 2 つの別個のストアド プロシージャに分割します。そうすれば、それぞれが独自のキャッシュされたクエリ プランを持つことができます。

また、テーブル変数では統計が作成されないため、一時テーブルを使用するように変換することで、パフォーマンスが大幅に向上する場合があります。

于 2013-06-11T23:57:13.610 に答える