如何給 SQL 存儲過程埋點？

點擊藍色“有關SQL”關注我喲

“埋點”，在前端技術中常用的技術，其實可以變?yōu)樗季S，應用到 SQL 的開發(fā)中。

之前做了很多業(yè)務系統(tǒng)的開發(fā)，架構涵蓋 C/S,B/S, C/C/S, 兩層，三層，n 層。在這些管理類軟件中，最頭通的不是界面寫的丑，也不是寫不出可用的程序，而是出了問題，不知道去哪一層找原因。

在耦合度還沒拆分那么細的那個年代，用戶追求的根本不是代碼的整潔，也不在乎你的代碼其他程序員能不能讀懂，他們要的很簡單，數(shù)據(jù)一致，數(shù)據(jù)安全。你的程序要丟了他們的數(shù)據(jù)，嘿嘿，加班吧。

所以，那個年代最普遍的做法，try…catch… 捕捉到的錯誤，經(jīng)常調一個email接口，及時發(fā)送給開發(fā)者。

久而久之，大家都知道，其實我們做程序，就是在救火而已。

那怎么辦呢，天天救火，怎么深入研究自己感興趣的事情呢？于是有人大膽想出來一個主意，讓所有的錯誤，異常信息，都直接保存到數(shù)據(jù)庫里面去。這就是業(yè)務系統(tǒng)最初的 log.

根據(jù)這份 log, 我們開始了大量的分析，有段時間，最熱衷的事情，就是看 log 跑出來的報表，特別有意思。比如：

1) 今天誰誰誰登錄了軟件系統(tǒng)，用了什么密碼（好像說漏嘴了），看了哪些報表，發(fā)表了哪些有意思的帖子；
2) 今天有多少用戶使用了我們開發(fā)的軟件，平均使用時間多少，在哪個地區(qū)或辦公區(qū)登錄的人最多；
3) 今天爆了一個不尋常的bug，它的用戶行為路徑是什么樣的，當時數(shù)據(jù)庫服務器的統(tǒng)計快照拉出來分析；

等等。

這些在今天我們依然在做，不過大部分的前端埋點都已經(jīng)放到了 nosql 數(shù)據(jù)庫中，不再去浪費正兒八經(jīng)的業(yè)務系統(tǒng)核心數(shù)據(jù)庫資源。

就拿淘寶來說，他們業(yè)務快速發(fā)展的那幾年，采用了大量的小機。小機的成本比較高，除了小機的硬件，還要考慮數(shù)據(jù)庫每年的維護費，持續(xù)記錄這些不核心的數(shù)據(jù)，顯然是不合算的。如果換成正常的 x86 服務器，那么成本會小很多，至少存儲可以省掉 一大塊。

因此有了 Nosql 的大量應用，比如 MongoDB, ElasticSearch 等等。

雖然埋點已經(jīng)交給前端處理了，但少量的應用還是要依靠存儲過程。對于存儲過程成千上百行的sql, 簡直就是一個黑盒。要想知道黑盒中發(fā)生了什么，埋點思維少不了。因此前端使用的埋點技術，就可以順利借鑒到存儲過程，甚至是平時的 ad-hoc sql 腳本。

如上圖，就拿一個數(shù)據(jù)庫的存儲過程來說，入口是個簡單的 try, 緊跟著埋點記錄存儲過程執(zhí)行開始，等待執(zhí)行完畢，記錄下執(zhí)行完畢的時間。一旦中間有錯誤，就在 catch 部分加上對異常信息的捕獲。

這就是簡單的一個存儲過程埋點框架。這樣做的好處，一來可以定位存儲過程的執(zhí)行時間，監(jiān)控近期的執(zhí)行性能是不是夠好；二來可以定位是不是有異常發(fā)生，以及異常具體信息是什么；三，如果埋的夠細，當然更有利于平時故障分析。

這是比較老式的做法，互聯(lián)網(wǎng)朋友們不要學，你們應當把埋點前移，減少數(shù)據(jù)庫的壓力。傳統(tǒng)行業(yè)的從業(yè)者，這一套基礎還是要有意識，可以提高對故障的定位效率。

好了，留言說說你們平時，是怎么記錄和定位數(shù)據(jù)庫故障的吧？