MySQL存储过程优缺点

最近做的小项目中用到了MySQL的存储过程，因此在网上查了下存储过程的优缺点，加深了解。

先来看一下解释：存储过程（Stored Procedure）是在大型数据库系统中，一组为了完成特定功能的SQL 语句集，存储在数据库中，经过第一次编译后再次调用不需要再次编译，用户通过指定存储过程的名字并给出参数（如果该存储过程带有参数）来执行它。

创建存储过程

create procedure sp_name

@[参数名] [类型],@[参数名] [类型]

as

begin

.........

end

以上格式还可以简写成：

create proc sp_name

@[参数名] [类型],@[参数名] [类型]

as

begin

.........

end

/*注：“sp_name”为需要创建的存储过程的名字，该名字不可以以阿拉伯数字开头*/

调用存储过程

1.基本语法：exec sp_name [参数名]

优点

1.在生产环境下，可以通过直接修改存储过程的方式修改业务逻辑（或bug），而不用重启服务器。但这一点便利被许多人滥用了。有人直接就在正式服务器上修改存储过程，而没有经过完整的测试，后果非常严重。

2.执行速度快，存储过程经过编译之后会比单独一条一条执行要快。但这个效率真是没太大影响。如果是要做大数据量的导入、同步，我们可以用其它手段。

3.减少网络传输，尤其是在高并发情况下。存储过程直接就在数据库服务器上跑，所有的数据访问都在服务器内部进行，不需要传输数据到其它终端。但我们的用户服务器通常与数据库是在同一内网，大数据的访问的瓶颈会是硬盘的速度，而不是网速（可使用Redis缓存解决）。

4.方便DBA优化。所有的SQL集中在一个地方，DBA会很高兴。这一点算是ORM的软肋。不过按照CQRS框架的思想，查询是用存储过程还是ORM，还真不是问题——DBA对数据库的优化，ORM一样会受益。况且放在ORM中还能用二级缓存，有些时候效率还会更高。

 

缺点

1.SQL本身是一种结构化查询语言，加上了一些控制（赋值、循环和异常处理等），但不是OO的，本质上还是过程化的，面对复杂的业务逻辑，过程化的处理会很吃力。这一点算致命伤，即只能应用在逻辑简单的业务上。

2.不便于调试。基本上没有较好的调试器，很多时候是用print来调试，但用这种方法调试长达数百行的存储过程简直是噩梦。好吧，这一点不算啥，C#/java一样能写出噩梦般的代码。

3.没办法应用缓存。虽然有全局临时表之类的方法可以做缓存，但同样加重了数据库的负担。如果缓存并发严重，经常要加锁，那效率实在堪忧。

4.无法适应数据库的切割（水平或垂直切割）。数据库切割之后，存储过程并不清楚数据存储在哪个数据库中。