或許在應用程序代碼中找到的最常見的錯誤就是這樣的查詢請求：它不是使用准備好的查詢或程序，而是使用非參數特設的查詢從數據庫中請求數據。
不准備你的查詢或者不使用存儲過程會增加不必要的SQL Server計劃緩存。什麼是計劃緩存呢?簡單地說，它是SQL Server共享內存池的一部分，在這裡，解析、編譯和執行優化這些查詢之後，查詢執行計劃仍被保存。無論何時執行一個查詢，內存的這個區域都會被查找，以便確定現有的一個計劃是否可以重新使用來滿足一個查詢請求。重新使用計劃為數據庫引擎節約了潛在的CPU密集工作，例如，如果唯一的不同點是WHERE從句中正在使用的值，我們不得不一次又一次重新解析，重新編譯，重新優化查詢。這將導致查詢響應時間加快，服務器中的CPU壓力降低。
下面的Java代碼片斷提出一系列非參數特設查詢到AdventureWorks數據庫中，以此來獲得用戶銷售訂單數據。它通過循環，從AdventureWorks SalesOrderHeader表中前20張訂單中獲得信息。
圖一
讓我們用SQL Server 2005 DMVs來檢驗計劃緩存中特設查詢的效果。
select qs.usecounts, cacheobjtype, objtype, qt.text
from sys.dm_exec_cached_plans qs
cross apply sys.dm_exec_sql_text(qs.plan_handle) as qt
order by qt.text
go
運行查詢之後，我們可以從下面的圖中看到，每一個查詢執行都在內存中存儲了一個非常具體的計劃，該計劃沒有參數化，也沒有被數據庫引擎重新利用。因為這些計劃是如此的具體，所以任何這些計劃能夠被重新使用的可能性很小。很容易看到，如果這是一個使用頻率非常高的應用程序，那麼服務器內存會很快地消耗。
圖二
現在將調整Java代碼來准備這個查詢語句。在執行之前，我通過命令DBCC FREEPROCCACHE清除該計劃緩存，接著通過一個准備好的語句重新運行Java class：
重新審視這個計劃緩存，我們可以看到，該查詢已經成功編譯並且重新用於所有的執行，因此有效地使用和保存服務器內存和限制CPU使用。
圖四
現在，考慮到由於計劃緩存是內存共享池的一部分，那麼消除多余的計劃可以為其他緩存騰出更多可用內存，從而使其他的緩存可以使用這個共享池，比如存儲已經從硬盤中讀取到內存中的數據和索引頁的SQL Server數據緩存。
雖然相對於使用非參數特設的查詢請求來說，准備好的查詢是一種更好的方法，但是比起這兩種方法，我個人更偏向於使用存儲過程。允許直接訪問你的核心數據庫表存在安全風險，通過存儲過程把數據從邏輯中抽取出來可以減少維護，並且當業務需求變化時，它也能夠減少數據模型的變化。無論你選擇哪種數據訪問方法，請記住通過確保你的查詢計劃是可以重復利用的，從而把你的應用程序從潛在的內存和CPU問題中解救出來。
