码迷,mamicode.com
首页 > 数据库 > 详细

MySQL 中存储过程的使用

时间:2015-03-03 01:07:31      阅读:249      评论:0      收藏:0      [点我收藏+]

标签:

    关于 MySQL 的存储过程,我所了解的一些有规模的公司,对于使用存储过程实现业务逻辑都有严格的限制。我这里搜罗了一些资料,结合自身的经验,总结一些自己关于 MySQL 中存储过程使用的认识。由于水平有限,如有纰漏错误,还请多拍砖。

 

    存储过程的优点主要包括以下几点:

 

1. 性能提高。相对于不使用存储过程来说的,因为存储过程在创建的时候,数据库已经对其进行了一次解析和优化,而后每次调用都不会再次编译,这相对于传统的SQL语句中每次调用都需要编译的情况来说,性能有所提高,存储过程经过编译之后会比单独一条一条执行要快。而存储过程一旦执行,在内存中就会保留一份,这样下次再执行同样的存储过程时,可以从内存中直接中读取。

2. 重用性强。存储过程使用名字即可执行,也就是传说中的“一次编写,随便调用”。并且是透明的,因为保存在数据库里所以对任何应用来说都可以使用。新的应用只需要调用相应的存储过程就可以得到相应的数据服务。这样不仅提高了重用性,还减少了出错的几率,也会加快开发速度。同时不依赖某种宿主语言,如果用多种语言开发,某些通用代码不用重复。

3. 减少网络流量。这一点对于小数据量的时候体现的并不明显。存储过程直接就在数据库服务器上跑,所有的数据访问都在服务器内部进行,不需要传输数据到其它终端,因此减少了应用服务器同数据库服务器的通信频率。调用一个行数不多的存储过程与直接调用SQL语句的网络通信量可能不会有很大的差别,可是如果存储过程包含上百行SQL语句,那么其性能就会比一条一条的调用SQL语句有较大的提升。

4. 安全性提高。存储过程是通过向用户授予权限(而不是基于表),它们可以提供对特定数据的访问,而且参数化的存储过程可以防止SQL注入攻击,在一定程度上保证了安全性。DBA可以对那些没有权限访问数据库中的表的应用,赋予存储过程的权限来获得数据服务,这个时候这些存储过程好像我们编程里面的“接口”。对于安全性要求很高的系统,例如银行,基本上常用的操作都是通过存储过程或者函数来进行的,这样完全对应用”隐藏“了表。

5. 灵活性增强。由于存储过程可以使用流程控制语句来编写,使得它有着很强的灵活性,可以根据实际情况来执行不同的SQL语句,而不是只能单纯的简单的执行命令。而且存储过程还可以修改其逻辑而其他部分不用改变,也就是说,我们的表的结构改变了,我们可能只需要修改相应的存储过程即可,我们的Java或者PHP等程序不需要改变。

6. 减少工作量。当业务复杂的时候,如果我们不使用存储过程,那么就会需要先从数据库中取出来数据,然后经过计算,再放入到数据库中。这些都是有开销的,其中包括我们的Java或者PHP等程序连接数据库获取结果集等若干操作。如果我们使用了存储过程,那么直接在MySQL中就能完成修改。并且可以分布式工作,应用程序和数据库的编码工作可以分别独立进行,而不会相互压制。

7. 可维护性高。更新存储过程通常比更改、测试以及重新部署程序集需要较少的时间和精力。在生产环境下,可以通过直接修改存储过程的方式修改业务逻辑(或bug),而不用重启服务器。但这一点便利很多时候被滥用了。比如:直接在正式服务器上修改存储过程,而没有经过完整的测试,后果可能会非常严重。

 

    好,上面说了存储过程的优点,再来看看存储过程的缺点:

 

1. 编写和调试麻烦。MySQL本身并没有很像样的IDE来开发存储过程,我们很多时候还是需要一行一行的老老实实手写,这样就会比较麻烦。而存储过程的调试也是一个问题,没有很像样的调试工具,很多时候是用print来调试,而且在使用slowlog对MySQL进行性能分析时,只能记录整个存储过程的执行情况,却无法记录存储过程内具体语句的执行情况,对于调试长达数百行SQL的存储过程简直是蛋疼。

2. 性能优势不明显。在运行速度上,对于大多数的SQL语句来说,编译SQL的时间开销并不是很大,但是执行存储过程还需要检查权限等一些其他开销,所以,对于很简单的SQL,存储过程并没有很大的性能优势。而且,数据库毕竟主要用来做数据存取的,并不适合进行复杂的业务逻辑操作,承担业务压力会占用大量的系统资源(cpu、memory)。

3. 赘余功能。通常情况下,数据库服务器只向内网中的应用服务器提供服务,而且连接数据库的用户往往是同一个。对于除金融领域外的其他大多数程序来说,安全性方面的需求往往小于性能、功能等其他方面。所以,对于安全性方面的情况看上去很好,实际上优点有些多余。

4. 可移植性差。当我们的程序要更换数据库的时候,它的移植性相对于不适用存储过程要更复杂。而且MySQL的存储过程功能比起Oracle、SQLserver、乃至PostgreSQL 都要较弱一些。

5. 本末倒置。SQL本身是一种结构化查询语言,加上了一些控制(赋值、循环和异常处理等),但不是OO的,本质上还是过程化的,大量采用存储过程进行业务逻辑的开发时,由于不支持面向对象的设计,无法采用面向对象的方式将业务逻辑进行封装,从而无法形成通用的可支持复用的业务逻辑框架,面对复杂的业务逻辑,过程化的处理会很吃力。

6. 拓展性差。像MySQL这样的关系型数据库,出现CPU和IO瓶颈时,极难扩展,但是应用服务器出现CPU和IO瓶颈,特别是采用SNA架构的情况下,理论上可以获得无限的水平扩展能力,只需要加服务器就行了。这个方法比任何方法都见效快,而且往往也是成本最低的。

              

总结:

    对于MySQL来说,通常情况下,除了某些非常依赖数据处理的操作,其他的业务逻辑不应该使用存储过程来实现,而应该由应用层实现。

 

    PS:题外话,并不是每个应用的瓶颈都在数据库端。即便瓶颈在数据库端,具体问题具体分析,也要功能、性能、安全、成本、效率等多方面权衡,才能做出最合适的选择。

 

MySQL 中存储过程的使用

标签:

原文地址:http://www.cnblogs.com/muhu/p/4306008.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!