上千行存储过程有感!

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/u010695794/article/details/88076001

本文首发于个人微信公众号《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

展开阅读全文

没有更多推荐了,返回首页