存儲過程是數(shù)據(jù)庫領(lǐng)域中應(yīng)用非常廣泛的技術(shù)，關(guān)于它的利弊討論由來已久，我們這里針對存儲過程的兩個(gè)公認(rèn)度較高的優(yōu)點(diǎn)進(jìn)行剖析，從而更清楚存儲過程的潛在風(fēng)險(xiǎn)及應(yīng)用場景。

存儲過程利于界面與邏輯分離!

界面與邏輯分離是現(xiàn)代應(yīng)用開發(fā)的一個(gè)基本準(zhǔn)則。相對于后臺數(shù)據(jù)處理邏輯，界面會有更多樣性的環(huán)境，如PC、手機(jī)等，而且業(yè)務(wù)穩(wěn)定性也不強(qiáng)，經(jīng)常會改。如果能把兩者分離，開發(fā)和維護(hù)界面時(shí)綁著數(shù)據(jù)處理邏輯一起改，成本就低很多。

支持存儲過程的觀點(diǎn)認(rèn)為，使用存儲過程能實(shí)現(xiàn)界面與邏輯分離。存儲過程在后臺數(shù)據(jù)庫中運(yùn)算，只要向前端提供數(shù)據(jù)，而不必關(guān)心界面的形式和異動。把所有的數(shù)據(jù)處理邏輯都寫成存儲過程，還有利于統(tǒng)一數(shù)據(jù)的出入口，易于實(shí)現(xiàn)數(shù)據(jù)權(quán)限管控。

但是，仔細(xì)想想會發(fā)現(xiàn)，實(shí)現(xiàn)界面與邏輯分離并不是存儲過程的專利。只要做一個(gè)數(shù)據(jù)訪問層，所有數(shù)據(jù)的進(jìn)出都通過這個(gè)訪問層，也會有同樣效果，事實(shí)上也確實(shí)有些應(yīng)用是這么做的，但并不普遍。這是什么原因呢?這樣的數(shù)據(jù)訪問層和采用存儲過程有什么區(qū)別呢?

差別在于開發(fā)復(fù)雜度上。

數(shù)據(jù)處理邏輯會經(jīng)常涉及到批量結(jié)構(gòu)化數(shù)據(jù)的處理，而數(shù)據(jù)庫之外的程序設(shè)計(jì)語言在這方面能力都很弱，用Java寫個(gè)數(shù)據(jù)求和都要很多行，更不要說過濾、分組之類的運(yùn)算了。而存儲過程的基本部件是SQL，這方面支持得很好，雖然存儲過程也有開發(fā)調(diào)試?yán)щy的毛病，但大多數(shù)情況下用于編寫復(fù)雜的數(shù)據(jù)處理邏輯還是要比高級語言更容易。

換句話說，存儲過程確實(shí)利于界面與邏輯分離，不過存儲過程實(shí)現(xiàn)后臺數(shù)據(jù)邏輯的優(yōu)勢是SQL的集合運(yùn)算能力支撐的。它主要來自于開發(fā)便捷，而不是應(yīng)用結(jié)構(gòu)。

有些場合無法利用存儲過程的計(jì)算能力，就只能實(shí)現(xiàn)庫外的數(shù)據(jù)訪問層了。比如數(shù)據(jù)來源涉及多數(shù)據(jù)庫或非數(shù)據(jù)庫的情況。

存儲過程利于界面與邏輯分離?

界面與邏輯分離的準(zhǔn)則還有兩面性，它并沒有明確定義什么程序算是界面，更沒有說界面環(huán)節(jié)就不再有數(shù)據(jù)計(jì)算任務(wù)。

一個(gè)典型的任務(wù)就是報(bào)表。報(bào)表要在界面中呈現(xiàn)，其業(yè)務(wù)穩(wěn)定性也較弱，經(jīng)常增改，很顯然屬于界面環(huán)節(jié)的事務(wù)。但是，報(bào)表經(jīng)常卻有復(fù)雜的數(shù)據(jù)源計(jì)算過程，如果把這部分計(jì)算也作為后臺邏輯強(qiáng)行放進(jìn)存儲過程中，則不僅不會獲得界面與邏輯分離的好處，反而帶來巨大的麻煩，這與網(wǎng)上許多推薦將復(fù)雜報(bào)表的計(jì)算過程中采用存儲過程的觀點(diǎn)正好相反。

報(bào)表的呈現(xiàn)模板一般是由報(bào)表工具繪制的，以文件形式存放在應(yīng)用中，如果數(shù)據(jù)源計(jì)算由存儲過程完成，則這兩個(gè)緊密相關(guān)的部分在物理上分別存放在兩處，要修改一張報(bào)表時(shí)需要兩個(gè)部分需要同步調(diào)整，不僅容易遺漏出錯，還可能增加溝通成本(兩部分的負(fù)責(zé)人員可能不同)。共享數(shù)據(jù)庫中的存儲過程還可能被其它報(bào)表甚至其它應(yīng)用調(diào)用，修改時(shí)就可能造成其它模塊的不正常。用存儲過程實(shí)現(xiàn)報(bào)表數(shù)據(jù)源會破壞應(yīng)用的模塊結(jié)構(gòu)，增大應(yīng)用的耦合度，造成維護(hù)成本升高。

采用存儲過程還會造成安全性和高效率的矛盾。原則上開發(fā)報(bào)表只需要對數(shù)據(jù)庫有只讀權(quán)限，但如果數(shù)據(jù)源是存儲過程開發(fā)的，則需要向報(bào)表開發(fā)人員開放編譯和運(yùn)行存儲過程的權(quán)限，這幾乎可以對數(shù)據(jù)庫做一切操作了，安全隱患非常大。一個(gè)辦法是加強(qiáng)管理，所有上載的存儲過程都需要多人審核把關(guān)，但這勢必會導(dǎo)致低效率，本來報(bào)表開發(fā)人員自己就能完成的事情要涉及更多崗位。

如果有不依賴于數(shù)據(jù)庫的便捷計(jì)算能力，則可以避免掉存儲過程的這些劣勢。把業(yè)務(wù)穩(wěn)定性不強(qiáng)、與界面相關(guān)緊密的計(jì)算移到數(shù)據(jù)庫外，和應(yīng)用程序集成到一起，維護(hù)成本更低。即使業(yè)務(wù)穩(wěn)定性強(qiáng)的計(jì)算邏輯也可以用庫外計(jì)算實(shí)現(xiàn)，解決多數(shù)據(jù)庫、非數(shù)據(jù)庫等多樣性數(shù)據(jù)源的問題。不采用存儲過程的整體應(yīng)用結(jié)構(gòu)更為合理。

存儲過程有更好的數(shù)據(jù)計(jì)算性能?

實(shí)際測試表明，用存儲過程實(shí)現(xiàn)數(shù)據(jù)計(jì)算，常常比用SQL取出數(shù)據(jù)后在外部計(jì)算的性能更好。存儲過程快在哪里了?

網(wǎng)上有觀點(diǎn)說，因?yàn)榇鎯^程是預(yù)編譯的，而每次執(zhí)行SQL時(shí)要臨時(shí)編譯，所以存儲過程會更快。其實(shí)編譯SQL的那點(diǎn)時(shí)間相對于數(shù)據(jù)計(jì)算而言可以忽略不計(jì)，以不同參數(shù)反復(fù)執(zhí)行的SQL也可以預(yù)先準(zhǔn)備，只要編譯一次。有些程序員把不同參數(shù)拼進(jìn)SQL，每次向數(shù)據(jù)庫發(fā)送不同SQL，編譯時(shí)間就不可忽略了。

存儲過程的快，主要在于數(shù)據(jù)不出庫。外部程序訪問庫內(nèi)數(shù)據(jù)時(shí)必須通過數(shù)據(jù)庫提供的接口，而這些接口的性能大都不好，特別是面向Java程序的JDBC接口。每次發(fā)出SQL讓數(shù)據(jù)庫執(zhí)行都會調(diào)用這個(gè)接口，速度就上不去。如果應(yīng)用程序和數(shù)據(jù)庫不在同一臺物理機(jī)器上時(shí)，還會有一些網(wǎng)絡(luò)延遲，不過和接口的低性能相比并不算嚴(yán)重。在外部計(jì)算時(shí)，從數(shù)據(jù)庫獲取數(shù)據(jù)的時(shí)間常常會超過計(jì)算本身的時(shí)間。

存儲過程本身的執(zhí)行性能并不好。我們針對某著名商用數(shù)據(jù)庫進(jìn)行過測試：一句SQL可以完成的運(yùn)算(比如對某個(gè)大表的字段求和)，如果改用存儲過程把數(shù)據(jù)一行行取出來計(jì)算，差不多會慢出一個(gè)數(shù)量級。用Java等語言從文件系統(tǒng)中讀數(shù)做同樣的計(jì)算，也會比存儲過程快很多;外部計(jì)算相對容易寫出并行代碼，充分利用現(xiàn)代服務(wù)器多CPU的優(yōu)勢，存儲過程一般都沒有這個(gè)機(jī)制了。而且，如果把很多計(jì)算都放到存儲過程中，并發(fā)運(yùn)算時(shí)會加重?cái)?shù)據(jù)庫的負(fù)擔(dān)，使本來就不快的存儲過程更慢。

存儲過程的性能更好，與其說是優(yōu)勢，倒不如說是被低效的數(shù)據(jù)庫訪問接口綁架所致。

目前業(yè)內(nèi)還只有關(guān)系數(shù)據(jù)庫有較好的交易一致性能力，適合充當(dāng)OLTP業(yè)務(wù)的后臺，這樣從前端采集到的數(shù)據(jù)會直接進(jìn)入關(guān)系數(shù)據(jù)庫，這導(dǎo)致原始數(shù)據(jù)大量存儲于數(shù)據(jù)庫中。如果要對這些數(shù)據(jù)進(jìn)行計(jì)算，采用外部計(jì)算方案時(shí)，取出數(shù)據(jù)太慢，總體性能就會很差;而使用存儲過程，雖然計(jì)算本身不快，但數(shù)據(jù)不出庫也會獲得較好性能。這是存儲過程不能被完全替代的主要原因和場景。