存儲過程
存儲過程（Stored Procedure）是在大型數(shù)據(jù)庫系統(tǒng)中月趟，一組為了完成特定功能的SQL 語句集灯蝴，它存儲在數(shù)據(jù)庫中，一次編譯后永久有效孝宗，用戶通過指定存儲過程的名字并給出參數(shù)（如果該存儲過程帶有參數(shù)）來執(zhí)行它穷躁。存儲過程是數(shù)據(jù)庫中的一個重要對象。
優(yōu)勢
- 可以減少程序在調(diào)用DB時候的信息傳輸量（其實減少的只有Request的時候）
- 存儲過程是預先優(yōu)化和預編譯的因妇，節(jié)省每次運行編譯的時間问潭，所以一般情況下認為存儲過程的性能是優(yōu)于sql語句的。
- 對調(diào)用者可以隱藏數(shù)據(jù)庫的復雜性，將數(shù)據(jù)組裝的過程封裝。
- 參數(shù)化的存儲過程可以防止SQL注入式攻擊襟企，而且可以將Grant槐雾、Deny以及Revoke權限應用于存儲過程。
- 如果業(yè)務開發(fā)中迂尝，數(shù)據(jù)人員和業(yè)務代碼人員是分離的，業(yè)務人員可以不用關心數(shù)據(jù)，直接調(diào)用存儲過程北专，更加面向分層開發(fā)設計理念。
劣勢
- 存儲過程這種“一次優(yōu)化旬陡，多次使用”的策略節(jié)省了每次執(zhí)行時候編譯的時間拓颓，但也是該策略導致了一個致命的缺點：可能會使用錯誤的執(zhí)行計劃。
- 存儲過程難以調(diào)試描孟，雖然有些DB提供了調(diào)試功能驶睦，但是一般的賬號根本就沒有那種權限腻格，更何況線上的數(shù)據(jù)庫不可能會給你調(diào)試權限的，再進一步就算能調(diào)試效果也比程序的調(diào)試效果要差很多啥繁。
- 可移植性差菜职，當碰到切換數(shù)據(jù)種類的時候，存儲過程基本就會歇菜旗闽。
- 如果業(yè)務數(shù)據(jù)模型有變動酬核，存儲過程必須跟著業(yè)務代碼一起更改，如果是大型項目适室，這種改動是空前的嫡意，是要命的。
不推薦存儲過程
以上存儲過程的優(yōu)缺點捣辆，你隨便一下網(wǎng)絡就可能查到蔬螟，表面看來存儲過程的優(yōu)勢還是不少的，這也說明為什么老一輩程序員有很多喜歡寫存儲過程汽畴。但是隨著軟件行業(yè)業(yè)務日益復雜化旧巾，存儲過程現(xiàn)在在復雜業(yè)務面前其實有點有心無力。
菜菜在業(yè)務中并不推薦使用存儲過程,辯駁請留言
- 采用存儲過程操作數(shù)據(jù)在網(wǎng)絡數(shù)據(jù)量傳輸上確實比直接使用sql語句要少很多忍些，但這通常并不是操作數(shù)據(jù)系統(tǒng)性能的瓶頸鲁猩，在一次操作數(shù)據(jù)的過程中，假設用時100毫秒罢坝，采用存儲過程節(jié)省數(shù)據(jù)傳輸時間0.5毫秒（就算是5毫秒）廓握，我覺得這點時間基本可以忽略。
- 存儲過程是只優(yōu)化一次的嘁酿，這有時候恰恰是個缺陷隙券。有的時候隨著數(shù)據(jù)量的增加或者數(shù)據(jù)結(jié)構(gòu)的變化，原來存儲過程選擇的執(zhí)行計劃也許并不是最優(yōu)的了闹司，所以這個時候需要手動干預或者重新編譯了娱仔，而什么時候執(zhí)行計劃不是最優(yōu)的了這個平衡點，預先無法知曉开仰，這就導致了有些應用突然會變慢拟枚，程序員處于懵逼的狀態(tài)。
- 存儲過程確實可以對調(diào)用方隱藏數(shù)據(jù)庫的細節(jié)众弓，但是這種業(yè)務代碼人員和數(shù)據(jù)庫設計人員是兩個團隊的情況又有多少呢恩溅，如果真是兩個團隊，那業(yè)務就需要兩個團隊來理解和溝通谓娃，我想溝通的成本也一定很高脚乡，而且分歧更容易產(chǎn)生。
菜菜認為數(shù)據(jù)庫就應該做它最擅長的事情：存儲相關。我不止一次的看過把業(yè)務寫在存儲過程的情況奶稠，程序代碼層面真是薄薄的貧血層俯艰，就是一個數(shù)據(jù)的透傳。我不贊同這種寫法锌订，因為我就接手過這樣的程序竹握，令我頭疼的不是業(yè)務，而是看著好幾千行的存儲過程熟悉業(yè)務辆飘，關鍵還沒有調(diào)試的權限（線上更不能調(diào)試）啦辐。
一個業(yè)務系統(tǒng)的設計往往需要你從數(shù)據(jù)庫的層面抽離出來，把主要精力放在業(yè)務模型的設計上蜈项，在程序?qū)用骟w現(xiàn)業(yè)務邏輯芹关，而不是把業(yè)務邏輯都交給數(shù)據(jù)層面的管理者。前幾天我排查過一個“Bug”：存儲過程是輸入?yún)?shù)是一個主鍵id的列表字符串紧卒，長度居然是 nvarchar（max）侥衬，主要功能是根據(jù)id列表查詢數(shù)據(jù)。我想說的是就算你是max的長度跑芳，也有超長的可能性發(fā)生轴总，因為業(yè)務方傳輸什么參數(shù)聋亡，參數(shù)什么長度是你DB無法控制的际乘，所以這類的業(yè)務一定要放在程序中做處理，而不是懷著僥幸心里丟給DB罪塔。
如果是抱著存儲過程性能高的心態(tài)的話养葵，我到時覺你這是誤入歧途关拒，菜菜認為存儲過程從來都不是提高性能的關鍵，反而系統(tǒng)的架構(gòu)着绊，緩存的設計归露，數(shù)據(jù)一致性更是系統(tǒng)關鍵問題。
存儲過程通常是一種解決方案恐锦，但是通常情況下不是唯一的解決方案，在選擇存儲過程作為方案前陕贮，請確保他們是正確的選擇潘飘。
最后秀一波存儲過程吧
更多精彩文章
