如何给 SQL 存储过程埋点？

点击蓝色“有关SQL”关注我哟

“埋点”，在前端技术中常用的技术，其实可以变为思维，应用到 SQL 的开发中。

之前做了很多业务系统的开发，架构涵盖 C/S,B/S, C/C/S, 两层，三层，n 层。在这些管理类软件中，最头通的不是界面写的丑，也不是写不出可用的程序，而是出了问题，不知道去哪一层找原因。

在耦合度还没拆分那么细的那个年代，用户追求的根本不是代码的整洁，也不在乎你的代码其他程序员能不能读懂，他们要的很简单，数据一致，数据安全。你的程序要丢了他们的数据，嘿嘿，加班吧。

所以，那个年代最普遍的做法，try…catch… 捕捉到的错误，经常调一个email接口，及时发送给开发者。

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

那怎么办呢，天天救火，怎么深入研究自己感兴趣的事情呢？于是有人大胆想出来一个主意，让所有的错误，异常信息，都直接保存到数据库里面去。这就是业务系统最初的 log.

根据这份 log, 我们开始了大量的分析，有段时间，最热衷的事情，就是看 log 跑出来的报表，特别有意思。比如：

1) 今天谁谁谁登录了软件系统，用了什么密码（好像说漏嘴了），看了哪些报表，发表了哪些有意思的帖子；
2) 今天有多少用户使用了我们开发的软件，平均使用时间多少，在哪个地区或办公区登录的人最多；
3) 今天爆了一个不寻常的bug，它的用户行为路径是什么样的，当时数据库服务器的统计快照拉出来分析；

等等。

这些在今天我们依然在做，不过大部分的前端埋点都已经放到了 nosql 数据库中，不再去浪费正儿八经的业务系统核心数据库资源。

就拿淘宝来说，他们业务快速发展的那几年，采用了大量的小机。小机的成本比较高，除了小机的硬件，还要考虑数据库每年的维护费，持续记录这些不核心的数据，显然是不合算的。如果换成正常的 x86 服务器，那么成本会小很多，至少存储可以省掉 一大块。

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

虽然埋点已经交给前端处理了，但少量的应用还是要依靠存储过程。对于存储过程成千上百行的sql, 简直就是一个黑盒。要想知道黑盒中发生了什么，埋点思维少不了。因此前端使用的埋点技术，就可以顺利借鉴到存储过程，甚至是平时的 ad-hoc sql 脚本。

如上图，就拿一个数据库的存储过程来说，入口是个简单的 try, 紧跟着埋点记录存储过程执行开始，等待执行完毕，记录下执行完毕的时间。一旦中间有错误，就在 catch 部分加上对异常信息的捕获。

这就是简单的一个存储过程埋点框架。这样做的好处，一来可以定位存储过程的执行时间，监控近期的执行性能是不是够好；二来可以定位是不是有异常发生，以及异常具体信息是什么；三，如果埋的够细，当然更有利于平时故障分析。

这是比较老式的做法，互联网朋友们不要学，你们应当把埋点前移，减少数据库的压力。传统行业的从业者，这一套基础还是要有意识，可以提高对故障的定位效率。

好了，留言说说你们平时，是怎么记录和定位数据库故障的吧？