最初に実行すると返されるのに約9秒かかり、その後の再実行では約4秒かかるクエリがあります。これについて読んだ後、これはプランのキャッシングの現れだと思います (間違っているかもしれませんが)。このクエリを最適化しようとしていますが、この影響によりそれが非常に難しくなっています。
これがプランのキャッシュの問題であるという私の分析は正しいですか、それとも他のオプションがありますか? もしそうなら、このキャッシュをローカルで無効にする方法はありますか (つまり、サーバーではなく、1 つのクエリに対して)。
最後に、option(recompile) がこの議論にどのように適合するかを説明します。
ちなみに私はSQLサーバー2008を使っていますが、
「FREEPROCCACHE」を使用してプランキャッシュをクリアできます
特定のプランをキャッシュからクリアする方法と例については、この MSDN ページを参照してください。
とはいえ、非常に長い SQL ステートメントでない限り、プランのコンパイルには 4 秒もかからないため、最初の実行後にクエリが高速に実行される原因となっているのはデータ キャッシュである可能性が最も高くなります。
プラン キャッシングではなく、データ キャッシングが原因である可能性があります。これには 2 つの方法があります。開発サーバーでは、実行
DROPCLEANBUFFERS
してデータキャッシュをクリアできます。最適化を行うには、クエリ プランと統計情報も使用する必要があります。この場合
SET STATISTICS IO On
、物理読み取りではなく論理読み取りに集中できます。データ キャッシュをクリアした後にクエリを 2 回実行すると、物理読み取りは劇的に低下しますが、論理読み取りは同じままです。
`OPTION RECOMPILE`
プランのキャッシュにのみ影響し、たとえば結果セットのサイズが劇的に変化した場合など、さまざまなパラメーターを渡すためにクエリ プラン自体が変更される状況でのみ違いが生じます。
論理読み取りを減らすには？一般的に言えば、インデックスとカバリングインデックスが思い浮かびます。実行計画を見ると、SQL サーバーが必要と判断した場合、インデックスを提案している可能性があります。実際には、適切なインデックス作成構文が提供されます (ただし、新しいインデックスが常に役立つとは限りません)。また、実際の実行計画で、返された行数が予想される行数と大幅に異なる場合は、統計を確認することをお勧めします。SQL サーバーはインデックス付きの列の統計を維持しますが、自動統計がオンになっていない場合、where ステートメントにインデックスのない列が含まれている場合は、その統計を生成する (またはインデックスを作成するか、自動統計をオンにする) ことができます。