程序員過關斬將--爲何不推薦業務中使用存儲過程？

菜菜哥，我新接手了一個項目，看的我頭疼呀

業務有這麼複雜呀？

不是的，這個老項目徹底是用存儲過程寫的，每一個存儲過程都好幾百行

這樣呀，是夠頭疼的~

有沒有辦法幫我瞭解業務一下？

碰到這樣的狀況，我真幫不了你了，你能夠多埋怨幾句作的那我的~~~

存儲過程

存儲過程（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. 存儲過程確實能夠對調用方隱藏數據庫的細節，可是這種業務代碼人員和數據庫設計人員是兩個團隊的狀況又有多少呢，若是真是兩個團隊，那業務就須要兩個團隊來理解和溝通，我想溝通的成本也必定很高，並且分歧更容易產生。

菜菜認爲數據庫就應該作它最擅長的事情：存儲相關。我不止一次的看過把業務寫在存儲過程的狀況，程序代碼層面真是薄薄的貧血層，就是一個數據的透傳。我不贊同這種寫法，由於我就接手過這樣的程序，令我頭疼的不是業務，而是看着好幾千行的存儲過程熟悉業務，關鍵尚未調試的權限（線上更不能調試）。

一個業務系統的設計每每須要你從數據庫的層面抽離出來，把主要精力放在業務模型的設計上，在程序層面體現業務邏輯，而不是把業務邏輯都交給數據層面的管理者。前幾天我排查過一個「Bug」：存儲過程是輸入參數是一個主鍵id的列表字符串，長度竟然是 nvarchar（max），主要功能是根據id列表查詢數據。我想說的是就算你是max的長度，也有超長的可能性發生，由於業務方傳輸什麼參數，參數什麼長度是你DB沒法控制的，因此這類的業務必定要放在程序中作處理，而不是懷着僥倖內心丟給DB。

若是是抱着存儲過程性能高的心態的話，我到時覺你這是誤入歧途，菜菜認爲存儲過程歷來都不是提升性能的關鍵，反而系統的架構，緩存的設計，數據一致性更是系統關鍵問題。

存儲過程一般是一種解決方案，可是一般狀況下不是惟一的解決方案，在選擇存儲過程做爲方案前，請確保他們是正確的選擇。

最後秀一波存儲過程吧

THE END

●程序員修神之路--問世間異步爲什麼物？

●程序員修神之路--提升網站的吞吐量🤺

●程序員修神之路--🤠分佈式高併發下Actor模型如此優秀🤠

●程序員過關斬將--論商品促銷代碼的優雅性

●程序員過關斬將--請不要隨便修改基類

●程序員過關斬將--你的面向接口編程必定對嗎？

●程序員修神之路--高併發下爲何更喜歡進程內緩存

●程序員修神之路--高併發優雅的作限流