儲存過程的使用案例以及優缺點分析

阿新 • • 發佈：2021-02-14

技術標籤：Mysql mysql

今天學習了一天的儲存過程！！！不用小本本記下來總感覺會忘。

儲存過程

MySQL 5.0 版本開始支援儲存過程。

儲存過程（Stored Procedure）是一種在資料庫中儲存複雜程式，以便外部程式呼叫的一種資料庫物件

儲存過程是為了完成特定功能的SQL語句集，經編譯建立並儲存在資料庫中，使用者可通過指定儲存過程的名字並給定引數(需要時)來呼叫執行。

儲存過程思想上很簡單，就是資料庫 SQL 語言層面的程式碼封裝與重用

1.儲存過程的使用：

1.1儲存過程的語法結構

create procedure 儲存過程名稱(引數);//可以無參，也可以帶引數，和java的方法名差不多

有引數的設定：（in|out|inout 引數名稱資料型別）

in：輸入引數，表示該引數的值必須呼叫儲存過程時指定

out：輸出引數，表示可以被儲存過程改變，並且可以返回

inout：輸入輸出引數，在呼叫時指定，可以被改變和返回

1.2.呼叫儲存過程

call 儲存過程名稱(); //如果定義了有引數這裡也需要傳入引數，和java呼叫方法一樣

1.3 案例1（建立無參的儲存過程並呼叫）

DELIMITER $$
CREATE PROCEDURE amytest()

BEGIN

SELECT * FROM `ums_account`;

END $$
DELIMITER ;

CALL amytest();

釋：a. delimiter 定義結束符號開始定義了以$$作為結束，後面再次使用恢復為預設結束符分號，為了防止儲存過程體中的分號對其造成影響，因為系統會預設以分號作為結束。

b. 建立儲存過程的名稱後面不能帶分號，會出現語法錯誤。

c. call呼叫儲存過程時的引數必須一致，有參給參，無參穿孔即可，和java呼叫方法一樣。

1.4 案例2（傳入一個id，刪除該資料，並檢視剩餘的資料條數）

DELIMITER $$

CREATE PROCEDURE amy_pro2(IN cid INT,OUT num INT)

BEGIN

DELETE FROM `ums_login_greeting` WHERE id=cid;

SELECT COUNT(id) INTO num FROM `ums_login_greeting`;

END $$

DELIMITER ;

CALL amy_pro2( 1 ,@num);

SELECT @num;

釋：1. into num 表示將查詢出來的count(id) 賦值到該變數中。

2. @num 變數宣告。

3. select @num; 表示檢視該變數的值，也就是刪除了資料之後總數還剩多少條。

1.5 案例3（輸入2個數，計算出最後的結果）

DELIMITER //
CREATE PROCEDURE amy_pro3(IN n1 INT,IN n2 INT,OUT result INT)

BEGIN

SET result=n1+n2;

END //
DELIMITER ;

SET @n1=10,@n2=28;

CALL amy_pro3(@n1,@n2,@result);

SELECT @result;

釋：1. SET @n1=10,@n2=28; 表示聲明瞭2個變數

1.6 刪除儲存過程

drop procedure 儲存過程名稱；

drop procedure if exists 儲存過程名稱；

釋：以上2條的區別在於如果不存在該儲存過程第一條會報錯，第二條則不會

2.儲存過程優缺點

2.1優點：

1. 執行速度：對於簡單的sql，儲存過程沒有什麼優勢。對於複雜的業務邏輯，因為儲存過程建立時，資料庫已經對其進行了一次解析和優化。

儲存過程一旦執行，在記憶體中回保留一份，這樣再次執行的時候，可以直接從記憶體中直接呼叫，所以執行速度會比普通sql快。

2. 減少網路傳輸：儲存過程直接在資料庫伺服器上跑。所有的資料訪問都在資料庫伺服器內部進行，不需要進行傳輸資料到其他伺服器，所以這樣會減少一定的網路傳輸。但是在儲存過程中沒有多次資料互動，那麼實際上網路傳輸量和直接sql是一樣的。而且我們的應用伺服器與資料庫是在同一內網,大資料的訪問瓶頸會是硬碟的速度，而不是網速。

3. 可維護性：儲存過程有時候比程式更容易維護，這是應為可以實時更新DB端的儲存過程。有些bug，直接改儲存過程裡的業務邏輯就搞定了。

4. 增強安全性：提高程式碼安全，防止SQL注入。這一點SQL語句也可以做到。

5. 可擴充套件性：應用程式和資料庫操作分開，獨立進行，而不是相互在一起。方便以後的擴充套件和DBA維護優化。

缺點：

SQL本身是一種結構化查詢語言，但不是面對物件的，本質上還是過程化的語言，面對複雜的業務邏輯，過程化的處理會很吃力。同時SQL擅長的是資料查詢而非業務邏輯的處理，如果把業務邏輯放在儲存過程裡面，違背了這一原則。
如果需要對輸入儲存過程的引數進行更改，或者要更愛起返回的資料，則需要更新程式集中的程式碼來新增引數等等，這樣就比較繁瑣了。
開發除錯複雜，由於IDE的問題，儲存過程的開發除錯比一般程式困難。
沒辦法應用快取。雖然有全域性臨時表之類的方法可以做快取，單同樣加重了資料庫的負擔。如果快取併發嚴重，經常要枷鎖，那效率實在堪憂。
不支援叢集，資料庫伺服器無法水平擴充套件，或者資料庫切割。資料庫切割之後，儲存過程並不清楚資料儲存在那個資料庫中。

總結：

適當的使用儲存過程，能夠提高我們SQL查詢的效能
儲存過程不應該大規模使用，濫用。
.隨著眾多的ORM出現，儲存過程很多優勢已經不明顯。
SQL最大的缺點還是SQL語言本身的侷限性---SQL本身是一種結構化查詢語言，我們不應該用儲存過程處理複雜的業務邏輯——讓SQL迴歸它“結構化查詢語言”的功用。複雜的業務邏輯，還是交給程式碼去處理吧。