mysql數據庫的存儲過程

1、 什麼是存儲過程：

            存儲過程是一組可編程的函數，是爲了完成特定功能的SQL語句集，通過第一次編譯後再次調用不須要再次編譯，建立並保存在數據庫中，用戶可經過指定存儲過程的名字並給定參數(須要時)來調用執行。

            ps：存儲過程跟觸發器有點相似，都是一組SQL集，可是存儲過程是主動調用的，且功能比觸發器更增強大，觸發器是某件事觸發後自動調用；

2、 存儲過程優勢：

            推薦文章：https://www.cnblogs.com/doudouxiaoye/p/5804467.html

            執行速度更快。只有首次執行需通過數據庫服務器解析，後續被調用能夠直接，提升執行速度，由於預先編譯了。

            sql注入徹底屏蔽很是安全(防止sql注入避免了暴露表結構和字段)(安全能夠有其餘方案，更可能是一種總體取捨，而不是單純一方面考慮)

            當用不一樣語言編寫多客戶應用程序，或多客戶應用程序在不一樣平臺上運行且須要執行相同的數據庫操做之時。

存儲過程能夠避免SQL注入是什麼道理？

我以前覺得是能夠避免url中sql注入。後來才明白其實就是針對程序員或者技術而言的：技術徹底不知道表結構是什麼。獲取數據只須要調用存儲過程便可。原來是針對開發人員而言的，屏蔽他們對數據庫的權限(這麼看來，我以爲這些在電信，銀行作開發的程序員，其實技能很難提高的，就是調用寫好的存儲過程，不須要指導表結構，你也不用參與表結構涉及與優化，數據庫優化都不用管)，題外話。這樣子狀況下，放到互聯網去作開發反而經驗沒法套用了。

在url中注入方面。使用存儲過程與不使用存儲過程都是須要防範的。

存儲過程相似於函數，函數的參數預約了參數類型是int仍是char等。傳入的參數不是int型，會自動轉換成int型，從這個角度就是避免了sql注入(我以爲更可能是怕開發人員搞鬼 呵呵)。

看到網上有人說：用參數，只能說MS給咱們作了一些過濾，SqlParameter規定了你傳參數的大小類型
嚴格過濾還得你本身來 。

2、 存儲過程缺點：

3、 存儲過程缺點：

一、業務邏輯封裝在存儲過程當中。對數據庫的依賴性比較大。一旦要遷移數據庫,好比從oracle遷移到mysql等，之前的業務邏輯都得重寫

我就遇到一個問題，從一堆數據中找出知足條件的某些數據，把全部的數據從數據庫讀取到客戶端，而後計算，篩選數據！我問他爲何不考慮存儲過程，爲何不在數據庫端篩選數據？系統工程師回答的是，存儲過程對程序的移植性很差（若是換了數據庫，就得從新實現一套)

二、其實在互聯網高併發，大流量的狀況下，成熟的作法都是，計算層交給web層，數據庫只是存儲數據。儘可能少讓數據庫去作運算(也就是ifelse之類的邏輯判斷)，

三、  方便擴展。遇到數據庫性能瓶頸。單臺數據庫服務器永遠會存在瓶頸的(極限)，是扛不住的。集中式最終會被分佈式給替代，通常在互聯網環境下偏向於使用分佈式部署數據庫。分佈式通俗理解，要分庫，拆分表。拆分到多臺服務器上去。分散壓力。若是業務邏輯封裝在存儲過程當中。則很差這樣子作。由於存儲過程是依賴於某個具體的庫的。把計算層放到web層，那麼web端的程序只是從多個數據庫服務器聚合數據便可了。

google、阿里巴巴其實會經過不少mysql集羣來提升性能。

若是再讓我跟國企、電信、移動、銀行業的技術人員溝通，我仍然堅持，儘可能少使用存儲過程封裝業務邏輯。考慮成本,

其實，不少真正提升效率的終極辦法是使用緩存而不是在數據庫中運算，靠數據庫預編譯或減小網絡流量那點優化就能夠，那說明性能要求本來不高。

存儲過程做爲一種過期的語言，只能存在於較少的業務場景了，好比規範的數據倉庫數據清洗、標準、簡單的多數據庫操做等。
在良好的業務系統中應該儘可能拋棄存儲過程和觸發器之類的東西。
一、從設計角度看，邏輯封裝很重要，不是存儲過程那一點封裝，而是整個業務邏輯。若是把業務邏輯分散在程序代碼和存儲過程兩部分，其實是業務碎片化，不利於表述業務邏輯，形成後期閱讀維護的困難。

二、存儲過程自身並非一種結構化良好的語言，對於習慣於面向對象編程的人而言，簡直就是亂麻一堆。代碼可讀性在工程上很重要。
三、不少真正提升效率的終極辦法是使用緩存而不是在數據庫中運算，靠數據庫預編譯或減小網絡流量那點優化就能夠，那說明性能要求本來不高

四、若是有數據庫解耦的需求，就更不該該使用存儲過程

 

4、 存儲過程使用場景：

銀行業廣泛使用存儲過程封裝業務邏輯：

1． 系統的部分或所有數據來自現有數據庫，處於安全考慮，只對開發團隊提供幾條Select SQL（或存儲過程）以獲取所需數據，具體的表結構不予公開。
2． 開發規範中要求，全部牽涉到業務邏輯部分的數據庫操做，必須在數據庫層由存儲過程實現（就筆者工做所面向的金融行業而言，工商銀行、中國銀行、交通銀行，都在開發規範中嚴格指定）
3． 系統數據處理量巨大，性能要求極爲苛刻，這每每意味着咱們必須經過通過高度優化的SQL語句（或存儲過程）才能達到系統性能設計指標。

解決性能瓶頸，互聯網大部分仍是經過使用緩存來解決的，這跟銀行類系統"花費大價錢提升硬件和數據庫軟件的承載能力"思路是不一樣的。

 

我能夠概括爲：花費了大手筆購買的服務器，超強。聽說是整年不宕機，很是穩定。性能很牛逼。

那麼總結就有錢，不在意這點錢。

多花錢，能解決我問題就好(保障穩定服務以及安全也很值得)。

我很是贊同這句話，安全很是重要的時候。銀行，金融業安全第一。其餘方面一律都不考慮(硬件花錢購買，軟件依賴於oracle之類昂貴的數據庫系統無所謂)

互聯網環境下，存儲過程用得仍是比較少的。安全性能夠有替代方案的。

 

1.學習存儲過程能夠在此處:

http://www.runoob.com/w3cnote/mysql-stored-procedure.html

2.mybatis使用存儲過程:

https://www.cnblogs.com/xdp-gacl/p/4270352.html