前段時間因為線下分析庫上的存儲過程SP無規范的泛濫，導致ETL和BI報表經常出現各種死鎖阻塞問題。遂決定動手整個簡單的SP編碼規范，其實主要目的就是記錄SP的運行日志和狀態。

存儲過程在很多“互聯網新生代”程序員的觀念里可能已經是上古物件了吧？現而今大部分的互聯網系統實現都不太可能采用存儲過程的實現方式，因為它對數據庫造成的負擔、難于調試、移植性差，以及在分布式、高并發場景下的天然劣勢，都阻礙了它的使用。所以阿里巴巴Java編程規范里明確規定“禁止使用存儲過程”也就不足為奇了。

但是很多公司的線下關系型分析庫上，SP仍舊是相當常用的一種技術手段。SP泛濫后主要容易出現以下幾點病癥：

1. 基于SP創建的Event運行頻率和運行時長設置的盲目且隨意。這會導致：

• SP自身本次還沒運行完，下一個自己就啟動了，結果自己把自己鎖死； 

• 不同SP之間有依賴順序，一旦前置SP出現超時，后續的SP執行只能是錯誤的或者鎖死的狀態；

2. SP的執行過程是黑盒、不可見的。準確的說就是SP在運行過程中沒有足夠的日志線索，很多時候只知道卡主了，但不知道卡在那里。

3. SP沒有異常處理。SP運行過程中發生錯誤，若沒有捕獲處理，導致最終運行失敗，那么這個SP在整個依賴鏈路的越前端，恢復成本將越高昂。

上述三個問題最終都可以靠一張日志表來解決，另外為了實現序號自增，又多建了一張序號表，總共2張表。

SP日志工具的代碼我已經上傳到了Github上，方便自己和大家翻閱。又因為本人特別喜歡Github上的Awesome系列，順道碰個瓷，這個代碼庫命名為了

awesome-stored-procedure

https://github.com/NicholasQu/awesome-stored-procedure

目前都是基于MYSQL編寫的，其他數據庫的有空再考慮完善一下吧。接下來簡單介紹下這幾個Function /Procedure。

/**********************************************

 *  使用示例

 **********************************************/

select getSeqNo('mall'), getSeqNo('pay');

功能：根據序號類別，獲取全局自增序號。

不同類別的交叉運行會導致序號跳空，該函數不保同一類別內序號的連續性。

/**********************************************

 *  使用示例

 **********************************************/

call logSpStart('sp1','testing sp1',100,@sp_exec_no);

call logSpStartAndCheck('sp1','testing sp1',100,'sp2', date_add(now(), interval -1 minute), now(), @sp_exec_no);

call logSpEnd('sp1','end sp1', @sp_exec_no);

SP啟動和先決條件檢查

用于記錄SP啟動時間和狀態，并檢查可以繼續運行的條件是否滿足：

1. 自身的運行頻度較高，之前自身是否還未運行完成。該情況調用logSpStart即可；

2. 依賴其他的SP運行完成，自身方能啟動。該情況需調用logSpStartAndCheck；

SP調試信息打印

用于打印Info級別的調試日志, 調用logSpInfo;

SP結束日志打印 logSpEnd

用于表示該SP已運行完成。注意這里只標識SP的完成，并不一定成功，整個SP中間過程可能發生了異常，但是繼續運行完畢了。

SP異常處理

對異常進行處理。有兩種方式：

1. 若該異常無關痛癢，可以繼續后續邏輯的話，使用logSpErrAndContinue;

2. 若該異常直接可以導致SP終止，調用logSpErrAndEnd;

標準SP寫法

參照 p_sp_demo.MYSQL.SP.sql

https://github.com/NicholasQu/awesome-stored-procedure/blob/master/recordSpLogs/p_sp_demo.MYSQL.SP.sql