探讨用存储过程的优劣

使用存储过程的优点：
1.开发速度非常快，基本上一个增删改查一个小时就能搞定
2.可以实时的更新业务逻辑代码不需要重新编译java代码，对于业务逻辑经常变的系统这点很有帮助
缺点：
1.数据量大时，对数据库的压力就非常大
2.对于热门资源访问量较大，容易形成堵塞，若存储过程写的不好，容易产生死锁。web层可以很容易无限的横向扩展，但数据库就只有一个，一但数据库堵塞了，整个系统也就差不多要挂掉了。使用存储过程会增加数据库服务器的负担。

我们公司就是将业务都写在存储过程里，现在经常都会堵塞，快要下班时系统就很慢。我们想了很多办法，将使用非常频繁且对数据库有压力的查询使用Lucene来完成。页面静态化，减少用户对数据库的访问。现在数据库的压力还是无法释放，正考虑换sql server2008,能将数据库的内存加到12G,可以缓解一点数据库的压力。

+1

其实SP还有一个很重要的功能：统一API。有时候一个数据库不仅仅就一个应用在操作，例如一个系统，它有web平台（Java），也有本地的CS平台（.NET）。这个时候就可以使用SP统一API。

当然，这种情景，你甚至可以用上一些中间件，例如ICE之类的。

SP有一个比较明显的缺点：部署的时候的版本控制比较麻烦。

回看楼主：

高并发下，不知道会不会有问题。完成一个业务过程，牵涉到许多表和好几个存储过程，里面有好几处是FOR UPDATE。设计时已经考虑到死锁问题，所以对多张表的更新顺序是保持一致的。但是高并发情况下会不会有性能问题，目前还未测试。如果有谁有经验，还望不吝赐教。

----------------------

这么多不确定能证明存储过程学习成本很低么？

存储过程只不过是预编译而已，能快到哪去啊？

效率多取决于代码的质量，对关系数据库的理解，不管用 sp 还是 orm 都是一样的。

说白了存储过程就是把标准 sql 这样一种经典的DSL，扩展为功能简单平淡无奇的解释运行的脚本语言， 表现能力有限，要复用和理解都不是那么容易。跟UI 的结合更没有一般的编程开发语言方便了。