我遇到了一種奇怪的情況，將OPTION (RECOMPILE)查詢追加到查詢中會(huì)使查詢?cè)诎朊雰?nèi)運(yùn)行，而忽略查詢會(huì)使查詢花費(fèi)超過(guò)五分鐘的時(shí)間。從Query Analyzer或C＃程序通過(guò)執(zhí)行查詢時(shí)，就是這種情況SqlCommand.ExecuteReader()。打電話（或不打電話）DBCC FREEPROCCACHE或DBCC dropcleanbuffers沒(méi)有區(qū)別；查詢結(jié)果總是在OPTION (RECOMPILE)不超過(guò)五分鐘的情況下即時(shí)返回。始終使用相同的參數(shù)調(diào)用該查詢（為了進(jìn)行此測(cè)試）。我正在使用SQL Server 2008。我對(duì)編寫SQL相當(dāng)滿意，但以前從未OPTION在查詢中使用過(guò)命令，并且在掃描此論壇上的帖子之前并不熟悉計(jì)劃緩存的整個(gè)概念。我從帖子中了解到，這OPTION (RECOMPILE)是一項(xiàng)昂貴的操作。顯然，它為查詢創(chuàng)建了新的查找策略。那么，為什么隨后的省略的查詢OPTION (RECOMPILE)是如此之慢呢？后續(xù)查詢是否應(yīng)該利用上一次包含重新編譯提示的調(diào)用所計(jì)算的查找策略？是否有一個(gè)查詢?cè)诿看握{(diào)用時(shí)都需要重新編譯提示是非常不尋常的嗎？對(duì)不起入門級(jí)的問(wèn)題，但我實(shí)在無(wú)法一馬當(dāng)先。更新：我被要求發(fā)布查詢...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.acctNoOPTION(RECOMPILE)從查詢分析器運(yùn)行測(cè)試時(shí)，我將在以下幾行前添加：declare @feedID intselect @feedID=20declare @feedDate datetimeselect @feedDate='1/2/2009'從我的C＃程序調(diào)用它時(shí)，參數(shù)通過(guò)SqlCommand.Parameters屬性傳遞。為了便于討論，您可以假設(shè)參數(shù)永遠(yuǎn)不會(huì)改變，因此我們可以排除次佳的參數(shù)氣味是造成這種情況的原因。