爲什麼如果我將查詢作爲參數化過程運行，它的運行速度會快10倍，如果直接將它作爲參數化查詢運行？爲什麼查詢速度很慢但SQL Server上的過程很快？
我在兩種情況下都使用完全相同的查詢，並且無論是從Management Studio調用還是從代碼中調用SqlCommand都無關緊要。
編輯：執行計劃看起來不同。所以爲什麼？我用完全相同的一組參數調用它。
編輯：經過更多的測試後，似乎只有在從SQL Management Studio運行參數化查詢時纔會出現10倍速度下降。
我最近看到的一件事是，如果你設置錯誤的查詢參數可能會導致重大問題。
例如，假設您有一個索引varchar列的參數，並使用SqlCommand的AddWithValue()方法從.Net進行設置。你在這個場景中受到傷害的世界。 .Net使用unicode字符串，並將您的參數設置爲nvarchar而不是varchar。現在，sql server將無法使用您的索引，並且您會看到顯着的性能損失。
找出它們是否使用相同的執行計劃是在運行時顯示它。在管理工作室中使用「包含實際執行計劃」，看看有什麼不同。
你打我的答案 - 我打字的時候你的答案到來。 – SAMills 2009-02-23 14:32:48
參數化查詢有很多advantages，其中包括經常性能提高。查詢
存儲過程可以運行，因爲速度更快執行計劃由sql server緩存。
但10倍的表現是可疑的。 在清除存儲的執行計劃後第一次運行相同嗎？您可以使用這些命令清除緩存。但他們清除了整個服務器緩存，因此只能在開發服務器上進行。
DBCC FREEPROCCACHE
DBCC FLUSHPROCINDB (<dbid>)
您是否直接在SQL服務器上運行這些以消除性能測試中的任何網絡I/O？
我的猜測是，它第一次運行緩慢，然後一旦緩存它運行得更快。
連接級別設置可以在某些情況下是至關重要的，尤其是ANSI NULLS，CONCAT NULL YIELDS NULL，等等。特別是，如果你有計算堅持索引列（其中包括推動「XML」列），那麼就不會信任預先計算的索引值如果設置不兼容，並且將重新計算每一行（即表掃描而不是索引查找）。
這是一個很好的觀點，我之前受到過傷害。 – 2009-02-23 14:34:48
我最近也看到了這種行爲。會造成一些重大的性能問題。 – Kibbee 2009-02-23 15:23:50
@Kibbee：我想這是你在一個或兩個月前的另一個SO問題中的評論，這讓我開始研究這種行爲。幸運的是，我永遠不會使用AddWithValue，並且總是明確指定參數類型，所以它在我的任何舊代碼中都不是問題。 – 2009-02-23 15:40:16