3

SQL Server 2005がある程度の実行プランのキャッシュを実行することは知っていますが、同じクエリを2回実行する間に時間差を生じさせるにはそれで十分でしょうか？初回は3時間かかり、次回は1分かかりますか？それも可能ですか？

4

4 に答える 4

3

SQL Server は実行計画だけでなくデータもキャッシュします

もしあなたがそうするなら

統計IOをオンに設定

出力を見ると、論理読み取りと物理読み取りが表示されます。論理読み取りはRAMから、物理読み取りはディスクからです。したがって、最初は物理読み取りの数値が表示されますが、再度実行すると論理読み取りの値が表示されます。

3 時間は長いように見えます。ブロック/ロック、古い統計などが原因である可能性もあります

于 2010-02-26T15:58:06.470 に答える
0

理論的には、最初の実行時 (「コールド ラン」) には、クエリに必要なテーブルとインデックス ページがディスク上に配置されている可能性があります。クエリがそれらをフェッチし、エンジンがそれらをキャッシュに入れました。

クエリの 2 回目の実行 (「ホット ラン」) では、キャッシュからのデータのみを使用しましたが、これはもちろんはるかに高速です。

ただし、3 時間は最大のキャッシュでもデータを取り込むのに十分すぎるため、これはほとんど当てはまりません。

ほとんどの場合、2 回目の実行では別の実行計画が使用されました (統計の更新が原因である可能性があります)。

于 2010-02-26T16:00:56.603 に答える
0

いいえ。クエリが最初にブロックされたとき (たとえば、別のセッションまたは成長イベントによって)、2 回目はブロックされなかった可能性があります。

例として、次のクエリを取り上げますINSERT INTO Table (Field) VALUES (1)。単純なクエリですが、最初に実行したとき、データベースがいっぱいで、拡張する必要がありました。データベースは 750 GB であり、既定の増加率である 10% のままであり、75 GB を作成する必要があります。これは、SQL Server サービス アカウントに[ボリューム メンテナンス タスクの実行]が許可されていないため、増加が約 30 分間続くためです。その後、クエリを再度実行すると、1 秒もかかりません。

ここでのポイントは、実行中に成長イベントが発生した、または発生しなかったということではありません。ポイントは、クエリが 3 時間続く場合は、その理由を理解する必要があるということです。アクティビティモニターは素晴らしいスタートです。Performance Tunning Wait Queuesのようなホワイト ペーパーを読むとさらに効果的です。

于 2010-02-27T19:18:05.023 に答える
0

いいえ！チャンスじゃない！

違いは他にあります！
クエリ プランを作成するのにかかる時間は、せいぜい数秒 (最悪) です。

おそらく、違いは次のいずれかによるものです。

  • キャッシュデータ
  • 他のクエリ/プロセスからのロックの有無
  • クエリの 2 回目の実行時に異なるデータ コンテキスト (参照される SQL オブジェクトの行数が少ないなど)

言及されている違い: 3 時間から 1 分程度までは非常に劇的であるため、キャッシュされたデータだけでは説明できないと思います。
ここで、クエリに関する詳細情報が役立ちます...
たとえば、まったく同じクエリが 2 回実行された場合でも、2 回目には異なる動作が発生する可能性があります (たとえば、これが更新/挿入/削除の場合)。クエリを入力すると、それほど多くの行を変更する必要がない場合があります)。基になるデータが (他のクエリ/プロセスによって) 変更されているため、SELECT のみのクエリでさえ、異なる方法で実行される可能性があります。

詳細を確認するためのいくつかの提案を次に示します。

  • 実行計画自体を（静的に）調べます。実際に 3 時間程度の費用がかかる可能性があるものがあるかどうかを確認してください。
  • 「統計をオン」にしてクエリを再実行し、各実行前にキャッシュをクリア (またはクリアしない) します。

キャッシュをクリアするためのステートメントは次のとおりです (新しいバージョンの SQL-Server では他の方法があるかもしれません)。

dbcc freeproccache
go
dbcc dropcleanbuffers
go
于 2010-02-26T15:58:24.567 に答える