為什麼不建議使用儲存過程了

在公司的系統公升級換代中，明確規定在資料庫開發中不允許再使用儲存過程了，以前的老一代系統中，很多複雜的業務邏輯都是儲存過程寫的，那為什麼風光無限的儲存過程不再被寵幸了呢？首先了解下什麼是儲存過程，它有什麼好處，又有哪些劣勢，為什麼現在都不建議使用儲存過程呢？

儲存過程（stored procedure）是在大型資料庫系統中，一組為了完成特定功能的sql 語句集，預先編譯好儲存在資料庫中，一次編譯後永久有效，使用者通過指定儲存過程的名字並給出引數（如果該儲存過程帶有引數）來執行它。它是資料庫中的乙個重要物件。

1、可以減少程式在呼叫db時候的資訊傳輸量（其實減少的只有request的時候）

2、儲存過程是預先優化和預編譯的，節省每次執行編譯的時間，所以一般情況下認為儲存過程的效能是優於sql語句的。

3、對呼叫者可以隱藏資料庫的複雜性，將資料組裝的過程封裝。

4、引數化的儲存過程可以防止sql注入式攻擊，而且可以將grant、deny以及revoke許可權應用於儲存過程。

5、如果業務開發中，資料人員和業務**人員是分離的，業務人員可以不用關心資料，直接呼叫儲存過程，更加面向分層開發設計理念。

1、儲存過程這種「一次優化，多次使用」的策略節省了每次執行時候編譯的時間，但也是該策略導致了乙個致命的缺點：可能會使用錯誤的執行計畫。

2、儲存過程難以除錯，雖然有些db提供了除錯功能，但是一般的賬號根本就沒有那種許可權，更何況線上的資料庫不可能會給你除錯許可權的，再進一步就算能除錯效果也比程式的除錯效果要差很多。

3、可移植性差，當碰到切換資料種類的時候，儲存過程基本就會歇菜。

4、如果業務資料模型有變動，儲存過程必須跟著業務**一起更改，如果是大型專案，這種改動是空前的，是要命的。

以上儲存過程的優缺點，表面看來儲存過程的優勢還是不少的，這也說明為什麼老一輩程式設計師有很多喜歡寫儲存過程。但隨著軟體行業業務日益複雜化，儲存過程現在複雜業務及大流量面前其實有點有心無力。

1、採用儲存過程運算元據在網路資料量傳輸上確實比直接使用sql語句要少很多，但這通常並不是運算元據系統效能的瓶頸，在一次運算元據的過程中，假設用時100毫秒，採用儲存過程節省資料傳輸時間0.5毫秒（就算是5毫秒），我覺得這點時間基本可以忽略。

2、儲存過程是只優化一次的，這有時候恰恰是個缺陷。有的時候隨著資料量的增加或者資料結構的變化，原來儲存過程選擇的執行計畫也許並不是最優的了，所以這個時候需要手動干預或者重新編譯了，而什麼時候執行計畫不是最優的了這個平衡點，預先無法知曉，這就導致了有些應用突然會變慢，程式設計師處於懵逼的狀態。

3、儲存過程確實可以對呼叫方隱藏資料庫的細節，但是這種業務**人員和資料庫設計人員是兩個團隊的情況又有多少呢，如果真是兩個團隊，那業務就需要兩個團隊來理解和溝通，我想溝通的成本也一定很高，而且分歧更容易產生。

我自己是有切身感受的，在接手的舊系統，令我頭疼的不是業務，很多重要的業務邏輯都寫在上千行的儲存過程，關鍵還沒有除錯的許可權，在生產上也不能除錯啊，出現個報錯，都不知道如何怎麼下手了。尤其是當有業務改動上線時，必須要停掉所以相關的儲存過程重新編譯，總有一些莫名其妙的問題出現，相當煩躁！

我認為資料庫就應該做儲存相關的事情，這也是它最擅長的事。現在的網際網路的大流量衝擊下，如果把業務處理及計算放在資料庫上，資料庫的負載壓力會特別大，肯定是頂不住的。再說了，現在搞的都是分布式集群，分布式資料庫，儲存過程已經不能勝任了。