使用存儲過程有沒有主要的性能提升？

Question

使用存儲過程還是以舊的方式使用連接字符串和所有好東西更好？我們的系統最近運行緩慢，我們的經理希望我們試着看看我們是否能夠加快一點，並且正在考慮將一些舊的數據庫調用改爲存儲過程。這值得麼？

Answer 1

首先要做的是檢查數據庫是否具有所有必要的索引設置。分析代碼速度慢的地方，並檢查相關的SQL語句和與其相關的索引。看看你是否可以重寫SQL語句以提高效率。檢查你是不是重複編譯循環中的每個迭代的SQL（準備）語句，而不是重複編譯一次。

將SQL語句移入存儲過程對於實現中的效率非常低效不會有幫助。但是，數據庫將知道如何最佳地優化SQL，並且不需要重複執行。它還可以通過將複雜的SQL語句轉換爲簡單的過程調用來使客戶端代碼更加清晰。

Answer 2

只要您的調用一致，數據庫將存儲執行計劃（MS SQL無論如何）。使用存儲過程最強有力的原因是爲了方便和可靠的安全管理。

如果我是你，我會首先尋找在需要的地方添加指數。還運行分析工具來檢查需要花費多長時間以及該sql是否需要更改，例如，添加更多Where子句或限制結果集。

你應該考慮緩存你可以在哪裏。

Answer 3

你不能提前說。您必須做到這一點，並衡量差異，因爲在10個案例中，有9個案例的瓶頸不在您想象的位置。

如果使用存儲過程，則不必傳輸數據。數據庫通常在執行[編輯]複雜[/編輯]存儲過程[編輯]時使用循環，高等數學等[/編輯]很慢。因此，這取決於您需要做多少工作，網絡速度有多慢，數據庫執行此特定代碼的速度有多快等。

Answer 4

我會快速瀏覽一下Stored Procedures are EVIL。

Answer 5

存儲過程不會讓事情變得更快。

但是，重新安排您的邏輯將產生巨大的影響。您在思考存儲過程時設計的整潔，重點突出的交易非常有益。

此外，存儲過程傾向於使用綁定變量，其他編程語言有時依賴於即時構建SQL語句。一小組固定的SQL語句和綁定變量很快。動態SQL語句很慢。

「最近運行緩慢」的應用程序不需要編碼更改。

1. 措施。測量。測量。在性能調整方面，「慢」並不意味着太多。什麼是慢？哪個確切的交易很慢？哪張桌子很慢？焦點。

2. 控制所有更改。所有。什麼改變了？ OS補丁？ RDBMS變化？應用程序更改一些東西改變了，以減緩事態。

3. 檢查比例限制。由於80％的數據是用於每年報告一次的歷史記錄，因此表格是否正在減速？

存儲過程從來不是性能問題的解決方案，除非您可以絕對地指向一個特定的代碼塊，這個代碼塊的存儲過程速度可以更快。

Answer 6

是的，存儲過程是朝着實現良好性能邁出的一步。主要原因是存儲過程可以預編譯並執行計劃緩存。

然而，您需要首先分析您的性能瓶頸在哪裏 - 以便您以結構化的方式進行此練習。

因爲它在其中一個答覆有人建議，嘗試使用Profiler工具是哪裏的問題分析 - 例如，你需要創建索引...

乾杯

Answer 7

如果您的服務器越來越在繁忙的季節明顯較慢，這可能是因爲飽和而不是數據庫中的任何不足。基本的queuing theory告訴我們，服務器在接近飽和時會雙曲線變慢。

基本關係是1/(1-X)其中X是負載的比例。這描述了平均隊列長度或服務之前要等待的時間。因此，當負載激增時，飽和的服務器會非常迅速地減速。

對於某些常數K（鬆散地說，K是機器執行一次事務的時間），裝載25％的服務器的平均服務時間爲1.333K。加載50％的服務器的平均服務時間爲2K，加載90％的服務器的平均服務時間爲10K。 考慮到減速本質上是雙曲線的，它通常不會對整體負載進行大的改變，從而導致響應時間顯着下降。

很明顯，這很簡單，因爲服務器將同時處理多個請求（這種情況下有更復雜的排隊模型），但寬泛的原則仍然適用。

因此，如果您的服務器出現飽和的瞬態負載，您將會遇到顯着減速的補丁。請注意，這些減速只需要在系統的一個瓶頸區域內放慢整個過程。如果您現在只是在繁忙的季節遇到這種情況，那麼您的服務器可能會對資源造成嚴重限制，而不是特別慢或效率低下。

請注意，這種可能性與代碼中效率低下的可能性並不矛盾。您可能會發現緩解瓶頸的方法是調整一些查詢。

爲了判斷系統是否瓶頸，請開始收集分析信息。如果你可以找到大量等待的資源，這應該給你一個很好的起點。

最後的可能是你需要升級你的服務器。如果代碼中沒有主要的低效率（如果分析沒有顯示任何不成比例的大瓶頸，這可能就是這種情況），您可能只需要更大的硬件。我不知道你的卷是什麼，但不要打折你可能超過你的服務器的可能性。

Answer 8

如果存儲過程避免發送大量數據和/或避免往返於服務器，那麼存儲過程可以真正起到幫助作用，所以如果您的應用程序遇到這些問題之一，它們可能非常有價值。

Answer 9

完成研究後，您會發現在光譜的另一側有兩個極端的視圖。從歷史上看，由於諸如hibernate之類的框架的可用性，Java社區一直反對存儲過程，相反，.NET社區已經使用了更多的存儲過程，並且這種遺留過程甚至可以達到vb5/6。把所有這些信息放在背景中，遠離硬幣兩端的極端觀點。

速度不應該是決定反對或支持存儲過程的主要因素。使用hibernate和其他框架，使用內聯SQL可以實現sp性能。考慮維護和其他程序（如報告，腳本）可以使用應用程序使用的相同存儲過程。如果你的場景需要多個用戶使用相同的SQL代碼，那麼存儲過程是一個很好的候選人，維護將會更容易。如果情況並非如此，並且您決定使用內聯sql，請考慮在配置文件中將其外化以便於維護。

在一天結束時，重要的是什麼會使您的特定場景對您的利益相關者取得成功。

Answer 10

像所有上述帖子所建議的，你首先要清理你的SQL語句，並有適當的索引。緩存可能會非常棘手，我不能發表評論，除非我有更多關於你想要完成的細節。

但有一兩件事有關存儲過程，確保你不讓它產生動態SQL語句

，因爲一個，這將是毫無意義的，它可以承受SQL注入攻擊 ...這有發生在我研究的其中一個項目中。

我會推薦sprocs主要更新，然後選擇語句。 祝你好運:)