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