上千行存储过程有感！

本文首发于个人微信公众号《andyqian》, 期待你来撩！

一

实话说，已经有一段时间没有写MySQL系列文章了，不过平常也一直在关注MySQL相关技术。就在前几天，偶然在知乎的时间线上出现了这么一个问题：

怎样评价一个几千行的sql存储过程？ (链接如下)

https://www.zhihu.com/question/311546275

 

说实话，看到这个问题，表示很震惊！当时就在想，是什么样的业务需要写上千行的存储过程？是什么样的系统需要写上千行的存储过程？

我的原回答是这样的：

首先：表明我的观点，站在现在来看，问我几千行的SQL存储过程怎么样？我只能说不好，不管你写的多漂亮，实现的功能多牛逼，在我眼里就是一文不值。(不接受反驳！)

原因如下：

1. 几千行的存储过程在我眼里，它代表的是曾经的C/S架构时代，也就是客户端时代。到在现在常用的移动互联网时代大都采用是B/S (Browser / Server) 架构，(我这里把app看成了B/S架构的Browser)。
2. 与之不同的是：C/S架构，大多数的逻辑是直接通过SQL来实现的，因为这是最快的，可能在当时也是最好的。在这个时代，不需要考虑高并发，RPC，分布式等问题（或者说，这个问题没有B/S时代突出）。但站在现在的角度来看：你再写几千行的SQL试试？估计一上线，CPU就该100%了，服务就该挂了。
3. 几千行的存储过程，一定是实现某个功能，或者实现某个业务。（在现在盛行的微服务里，服务粒度小，各司其责，能将服务最大化优化，修改成本低，可维护性更高）。维护几千行的存储过程你试试？别说别人了，就说自己写的，一周后大概都不知道什么意思了吧？

总的来说：几千行的SQL，在现在来看，性能 + 可维护性 简直就是噩耗！还有譬如：调试，可移植性，优化等都是不可想象的。

二

我们都知道，科技在发展，技术在进步，C/S架构到B/S架构的演化也伴随着很多技术上的挑战。从单体应用->MVC->RPC->微服务。其核心思想都是分而治之，分为不同的模块，模块下又分为不同的服务。服务内部操作缓存，操作数据库，使用队列。服务交互，程序处理，一环扣一环，交纵复杂。一个用户请求过来，只要某一环出现异常或者响应缓慢，都会造成体验卡顿，甚至无响应！

这样的大前提下，常用做法都是通过代码来实现业务逻辑。不会在数据库中进行复杂操作，甚至都不建议使用多表连接查询。因而，落到数据库中的一般都是简单SQL。即使是这样，也时常需要进行优化，其中优化的技巧又有很多学问。在生产系统中，慢SQL对于服务甚至系统而言，往往都是致命的。

现在再看看『上千行的存储过程』，不禁留下了一身冷汗！

---

 

最后：你遇到了哪些让你冒冷汗的事情？留言区一起分享下呗！

---

 

相关阅读:

《浅谈 Java JPDA》

《浅谈MySQL SQL优化》

《说几个拖垮系统的小细节！》

《写会MySQL索引》

                                                                                     扫码关注，一起进步

                                                                        个人博客: http://www.andyqian.com