OPTION (RECOMPILE)
クエリに追加すると 0.5 秒で実行され、それを省略するとクエリに 5 分以上かかるという奇妙な状況に遭遇しました。
これは、Query Analyzer または C# プログラムからSqlCommand.ExecuteReader()
. 電話する(または電話しない)DBCC FREEPROCCACHE
かDBCC dropcleanbuffers
、違いはありません。クエリの結果は、クエリがある場合は常に瞬時に返され、クエリがOPTION (RECOMPILE)
ない場合は 5 分以上返されます。[このテストのために] クエリは常に同じパラメーターで呼び出されます。
SQL Server 2008 を使用しています。
私は SQL を書くことにかなり慣れていますが、これまでOPTION
クエリでコマンドを使用したことがなく、このフォーラムの投稿をスキャンするまでプラン キャッシュの概念全体に慣れていませんでした。投稿からの私の理解は、それOPTION (RECOMPILE)
は高価な操作であるということです。どうやら、クエリの新しいルックアップ戦略を作成します。では、なぜ を省略した後続のクエリOPTION (RECOMPILE)
が非常に遅いのでしょうか? 後続のクエリは、再コンパイルのヒントを含む前回の呼び出しで計算されたルックアップ戦略を利用するべきではありませんか?
呼び出しごとに再コンパイルのヒントが必要なクエリがあるのは非常に珍しいことですか?
初心者レベルの質問で申し訳ありませんが、これについては頭も尻もわかりません。
更新: クエリを投稿するように求められました...
select acctNo,min(date) earliestDate
from(
select acctNo,tradeDate as date
from datafeed_trans
where feedid=@feedID and feedDate=@feedDate
union
select acctNo,feedDate as date
from datafeed_money
where feedid=@feedID and feedDate=@feedDate
union
select acctNo,feedDate as date
from datafeed_jnl
where feedid=@feedID and feedDate=@feedDate
)t1
group by t1.acctNo
OPTION(RECOMPILE)
Query Analyzer からテストを実行するときは、次の行を先頭に追加します。
declare @feedID int
select @feedID=20
declare @feedDate datetime
select @feedDate='1/2/2009'
C# プログラムから呼び出すと、パラメーターはSqlCommand.Parameters
プロパティを介して渡されます。
この議論の目的のために、パラメーターは決して変化しないと仮定できるため、最適ではないパラメーターの臭いが原因である可能性を排除できます。