存储过程系列之-为什么要使用存储过程，以及优缺点

深碍√TFBOYSˉ_ 2023-02-27 13:50 20阅读 0赞

## 一.为什么要使用存储过程 ##

存储过程是指在数据库系统中，一组为了完成特定功能的SQL语句集，存储在数据库中，经过第一次编译后以后再调用任意次都不需要重新编译了。说白了就是一堆SQL语句的合并，中间加了点逻辑控制，俗称为数据库中的函数。在一些金融等大型企业中，基本都是由内部人员编写好存储过程，然后由外部程序员调用存储过程，因为内部数据逻辑处理方式涉及商业机密等等。

也就是说我们现在有两种方式来处理数据库中的数据，一是通过JDBC从数据库中取出数据然后通过业务层编写处理数据的逻辑代码；二是在数据库中定义数据的存储过程，在这个存储过程中完成对数据的逻辑操作，就好比数据库中的函数，而我们在Java程序中只要调用数据库中的这个存储过程即可。

## 二.数据库存储过程具有如下优点 ##

1.  存储过程只在创建时进行编译，以后每次执行存储过程都不需再重新编译，而*一般 SQL 语句每执行一次就编译一次*，因此使用存储过程可以大大提高数据库执行速度。
2.  通常，复杂的业务逻辑需要多条 SQL 语句。这些语句要分别地从客户机发送到服务器，当客户机和服务器之间的操作很多时，将*产生大量的网络传输*。如果将这些操作放在一个存储过程中，那么客户机和服务器之间的网络传输就会大大减少，降低了网络负载。
3.  存储过程创建一次便可以重复使用，从而可以减少数据库开发人员的工作量。  
    *对于这句话的理解可能有的开发的同事，看的不明所以，咋就减少数据库开发人员的工作量，上面那句话形容的不是很贴切，对于开发人员来说，可以分两部分来写，一个是业务逻辑的开发，二是持久层对数据库操作的开发，咋就能减少开发人员的工作量，譬如，一个经常变动的业务，或者变动的业务规则，是不是每次变动以后，开发人员就要进行相应的业务处理，业务判断，可能还要调整持久层SQL，改完以后还要发布代码等等。试想如果我们一套业务逻辑都用存储过程来实现，是不是我们就不用太多的去关注，代码业务是怎么实现的，数据持久层是不是要做修改，我们用了存储过程只需要，调整存储过程的业务逻辑，改完以后只需要更新数据库环境中的存储过程即可。*
4.  安全性高，存储过程可以*屏蔽对底层数据库对象的直接访问*，使用 EXECUTE 权限调用存储过程，无需拥有访问底层数据库对象的显式权限。

正是由于存储过程的上述优点，目前常用的数据库都支持存储过程，例如 IBM DB2，Microsoft SQL Server，Oracle，Access 等，开源数据库系统 MySQL 也在 5.0 的时候实现了对存储过程的支持。

**定义存储过程:**

delimiter //
    
    create procedure addPrefix(in inputParam varchar(255),inout inOutParam varchar(255))
    
    begin
        select concat('long live sd...',inputParam) into inOutParam;
    end //
    
    delimiter ;

**分析：**

1.  第一行我们将MySQL中的分隔符先定义为“//”，因为等会在存储过程的逻辑代码中会使用到“;”，不先定义别的分隔符的话逻辑代码还没写完数据库就执行了。
2.  第二行定义存储过程的名称，同时在参数列表中定义参数输入输出类型(IN,OUT,INOUT)，参数名称，参数类型(SQL数据类型)。
3.  第三行开始以关键字“BEGIN”开始，以“END”和刚才定义的分隔符结束，在这两个中间就是平常的SQL语句了，也就是在这个部分编写我们处理参数的逻辑。
4.  最后，我们将MySQL数据库的分隔符重新定义回分号“;”。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaW5pY2hlbmRpYW4_size_16_color_FFFFFF_t_70]  
这篇文章是博主从腾讯云博客拷贝的，开始还没有运行出来，也无法分辨这上面写的SQL能不能正常的运行。只能说自己看懂了上面写的类容。于是还是觉得从头开始学习，系统的学习一下存储过程，上面的问题就能迎刃而解。自己看了看发现存储过程是真的强大，为什么实际开发工作中写的很少，自己总结无法一下几个原因。

1.  移植性不是很好，就是譬如从MYSQL迁移到Oracle。我现在觉得这种说法十分的牵强，Oracle难道就没有存储过程，或者可能每个数据库语言都有自己的痛点，但是存储过程要是十分的遛那就都不是问题，毕竟现在的数据库体系已经很成熟了，不会有太大的短板。
2.  因为语言的侧重点不同，譬如我是学java的，我的侧重点就在java语言上，数据库我会学，但是也是学它一些主要的用法，例如：sql的拼写、效率的执行、索引的添加等等，存储过程这种实际工作中不怎么用到我不会太去关注。
3.  固定的思维模式，因为我呆过的几家公司，印象中就第一家用过存储过程，而且那时我刚毕业，看了下，没做深入的研究，后面的公司也没再涉及到了，哪怕我呆过了好几个上市公司。开发模式已经固定，框架也固定，开发人员也习惯性的使用固定化的框架等等。
4.  还有可能就是代码有分层有独立封装的业务点，后面新手维护，啥的比较方便，不会因为你走了，导致别人接你工作的一脸蒙蔽，特别是存储过程写的特别复杂的时候，还穿插复杂业务逻辑的时候，那别人杀你的心都有了。
5.  对于很简单的SQL语句，存储过程没有啥优势。现在的数据语言已经十分完善，对于简单的SQL效率差异还不是很明显。
6.  存储过程不一定会减少网络传输，我们减少网络传输的前提是，你的存储过程SQL足够多，业务足够复杂，简单的SQL网络传输就量而言本身就很少。
7.  如果只有一个用户使用数据库，安全性也没有那么明显了。
8.  在大并发量的情况下，不宜写过多涉及运算的存储过程，并发量与性能成正比的，还是存在一定的瓶颈。
9.  业务逻辑复杂，特别是对很大的表进行操作时，为了均衡各个端的性能，应该更好的再前端，后台简化业务逻辑，减少对数据库的依赖，毕竟数据库也是有瓶颈的。尽量还是让数据库的功能更本质，即基本的增删改查。

这样几点我看着自己都笑了，为什么存储过程没有推广开，还有的公司面试问了你会不会存储过程，但是了，个人感觉存储过程使用要慎重，千万不要处理复杂的业务逻辑。特殊的系统，譬如秒杀需要强一致性的时候，可以考虑使用存储过程。

还有存储过程的使用要有一定的限制，要把握好一个度，存储过程也不要过于复杂，互联网也不太适合，因为要考虑并发的问题，移植的问题，后期维护的问题等等。企业内部软件如果遇到需要性能提升方面的考虑，可以考虑使用存储过程，因为内部的软件一般是固定的，变动的也不会很频繁，加之并发量也是非常小的。

具体的使用还是要看场景，以及使用过程中的压测数据对比，那种更加优秀，通过性能数据一目了然，后面涉及存储过程会对存储过程以及普通的SQL性能进行对比。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaW5pY2hlbmRpYW4_size_16_color_FFFFFF_t_70]: /images/20230209/1157716f2ca24353ae60430393c33dab.png