私は最適化に取り組んでいるクエリが遅いです。SQL Server - Management Studio - クライアントの統計 - サーバーの応答時間とクライアントの処理時間の比較
Management Studioでクライアント統計を見ると、サーバー応答で約8秒、クライアント処理時間で約1秒かかりました。
私はいつも、サーバー応答の待機時間が作業する数であり、クライアントの処理時間は一般的に帯域幅または大きなデータサイズに関連していると考えてきました。
私はクエリにいくつかの変更を加えましたが、サーバー応答の待機時間は約250msですが、クライアントの処理時間が約9秒に増加し、合計実行時間がわずかに遅くなりました。
返される結果セットはまったく同じです。
この2つの数字の違いがどういうものなのか、何が原因でしょうか？
「サーバー上での時間を待って返信のクライアントを残し、非常に最初の応答パケットから返された最後の要求パケットの間の時間でありますサーバー。 「クライアント処理時間」は、最初の応答パケットと最後の応答パケットとの間の時間である。 Btw、私はこれらの主張を裏付けるための文書を見つけることができませんでしたが、私は私の観察に基づいて、彼らは教育された正当な推測であると言います。
「サーバー応答で待機時間が長い」クエリを実行すると、サーバーが最初の行を生成するのに時間がかかったことを意味します。これは、サブクエリ全体を処理する前に評価する必要のある演算子を持つクエリ（通常の例はソート演算子です）では通常です。
一方、「サーバー応答の待ち時間」が非常に短いクエリは、クエリが最初の行を高速に返すことができたことを意味します。しかしながら、長い「クライアント処理時間」は、必ずしもクライアントが処理に多くの時間を費やしたことを意味するものではなく、サーバはクライアント上で待機していることを意味する。これは単にサーバーが結果から行を返すことを意味し、最後の行が返されるまでの時間です。
実行計画を変更した結果、実行をブロックしていた演算子（おそらくソート）が削除された可能性があり、新しい計画では最初の結果を速くする別の戦略が使用されます要求された順序が保証されているので、ソートは必要ありません）、全体的にはさらに長くなります。あなたは、クライアントがサーバーをバック保持を心配している場合
調査中のクエリを実行するセッションのために、あなたは（もsys.dm_os_tasksとsys.dm_os_workersからの情報が便利です）sys.dm_exec_requestsでwait_typeを調査する必要があります（大量の結果セットに発生する可能性があります） 。私が誤っていない場合、クライアント待機タイプで待機しているサーバーはASYNC_NETWORK_IOです。集約sys.dm_os_wait_statsを確認し、DBCC SQLPERF("sys.dm_os_wait_stats" , CLEAR)を使用してリセットしてから、照会を実行して、ASYNC_NETWORK_IO待機タイプがどのくらい長くなるかを確認することもできます。もちろん、テスト中にサーバー上で他のアクティビティが発生していないことを確認してください。
私はそれらの意味も同じだと思ったのです。重要なことは、両方のクエリで同じ外向きの並べ替え順序があり、この並べ替えを変更して、同じ出力内のすべての静止結果にインデックスが設定されていない列を含めることです。私はいくつかのウェイティングタイプとネットワークioのものを見てみましょう。ありがとう。私はまだこのすべてを示すテストハーネスに取り組んでいます。うまくいけばそれはもっと意味をなさないでしょう。 –
[OK]をクリックすると、この件に関する記事が見つかりました。彼らが役に立つと願っています。私はこれがクエリのパフォーマンスチューニングに関する私にとって新しい種類のドアを開いたと言わなければならない。
SQL Server Wait Events: Taking the Guesswork out of Performance Profiling
Analysing Query Performance in SQL Server 2005
これらのおかげで、私は読んでみましょう。実行していたクエリを投稿できません。それはむしろ大規模なものであり、多くのバックグラウンドがなければ意味をなさないでしょう。私は同じ結果を生む簡単なテストハーネスに取り組んでいます。私が終わったらすぐに投稿します。 –
これらの統計情報は次のとおりです。http://msdn.microsoft.com/en-us/library/aa216969(v=SQL.80).aspx
リンクが切れています。 http://msdn.microsoft.com/en-us/library/aa216969(v=SQL.80).aspxまたはhttp://technet.microsoft.com/en-us/library/aa216969(v=sql）を試してください。 80）.aspxを使用するか、または「クエリウィンドウ統計ペイン」で検索します。 –
実行しようとしているクエリは何ですか？ –
さらに調査したところ、この問題はクエリ内のテーブル値付きUDFに結合していました。これにより、SOS_SCHEDULER_YIELD がクエリの各行を待機していました。テーブルへのパラメータは固定されていますので、一時テーブルにそのテーブルを設定して結合しました。両方の答えが私を助けてくれました。彼が私が見ていた2回についての私の考えを確認し、待つための正確な命令を与えたので、私はRemusにそれを与えるつもりです。 –