存儲過程與數據庫查詢中的代碼

Question

訪問數據庫以使用 ASP.NET 代碼進行查詢與使用 SQL 存儲過程之間的性能差異是什么？

為了便於使用，對查詢進行編碼更容易，尤其是在進行維護和更改時。

但是，存儲過程是在數據庫中編譯並由數據庫運行的。

哪個更有效，更好用？

Answer 1

SQL Server 緩存任何查詢的執行計划，無論是否為 SPROC。 這里幾乎沒有區別。 基本上，您可以在使用 sproc 時通過網絡發送查詢文本，僅此而已。 來源： http : //msdn.microsoft.com/en-us/library/ms181055.aspx

在沒有特殊原因的情況下，做對你來說更方便的事情。

其他表明 sproc 性能通常更好的答案是不正確的。

Answer 2

只要它是以數據庫為中心的查詢，那么存儲過程在大多數情況下將是更快的選擇（性能）。

但它更難維護，因為它不在您的常規源包中。

“更好用”取決於要求。 如果查詢速度稍慢（例如 1 ms VS 3 ms）還可以，那么將您的代碼放在一起並將其放在 ASP 中。 如果性能是您想要的東西，請將其放入數據庫中。

我將大部分查詢放在代碼中，並且只將那些需要數據庫中的性能。

當然，這也取決於所使用的數據庫系統。

Answer 3

關於您實際比較的內容，您的問題非常不完整。

SQL 代碼是在存儲過程中還是在客戶端提交的完整的內聯 SQL 語句中，通常對性能幾乎沒有影響（假設參數化正確且 SQL 是非病態的）。 它可以在安全體系結構和訪問基表或視圖而不是過程的執行權限方面產生很大的不同。 存儲過程鼓勵將參數化作為一項要求，但使用內聯 SQL 也可以進行參數化。

如果您正在談論對從數據庫返回的集合執行邏輯而不是在數據庫中執行工作，這可以是雙向的 - 這取決於操作類型、索引類型、客戶端和數據庫之間的帶寬以及請求數量需要維修。

通常，我會首先在數據庫中執行此操作，以保持從客戶端抽象出來的連接/循環邏輯並減少線路上的數據（列和行）並向客戶端提供一個簡單的數據集 API，但它取決於.

Answer 4

這是一個“視情況而定”的問題。
假設這是 SQL Server 2008R2 或更高的標准版或企業版，存儲過程的緩存將與 TSQL 語句不同。 由於參數化、代碼編譯、參數嗅探和各種其他優化等多種因素，復雜的 T-SQL 語句的性能幾乎總是比存儲過程差。 一般來說，我更喜歡存儲過程，因為它們更容易優化。 此外，您無需重新編譯和重新部署任何代碼即可更改存儲的程序。 並且優化（例如“優化未知”或“重新編譯”可以應用於參數值劇烈變化時的存儲過程）可以應用於存儲過程並在最終用戶甚至沒有注意到的情況下取消（好吧，除了性能變化）。

一次運行后，存儲過程將始終在計划緩存中結束，並且永遠不會被視為即席查詢。 臨時查詢，取決於 SQL 設置，可能會或可能不會存儲在計划緩存中。 加上添加或刪除字符（假設它沒有參數化）將導致 SQL Server 構建新計划，而構建新計划是一個緩慢的操作。

TL;DR - 使用 SQL Server 2008R2 或更高標准/企業版； 對於簡單的查詢，您會發現沒有區別。 對於復雜的查詢，存儲過程（如果編寫得當）幾乎總是會執行 T-SQL。 存儲過程也更容易在以后優化。

編輯 - 在 SQL 版本中添加。 我不確定舊的 SQL 版本。