QQ群的人身“交流”-- 引发的使用数据库讨论

本来今天是不想在写下去了，今天比较累，脑子嗡嗡的。或许想学的东西太多，而我的脑容量太小。下了班坐在轻轨上，本来想在看看ORACLE 的东西，但实在是脑子不给力，翻开手机，上了已经1个多月都没有上的QQ群。

作为SQL SERVER 某群的管理员，去年经常给别人解答问题，被送上大神的称号，其实只是愿意用自己那点知识，去热心交流而已。当我登上群，立即傻眼，两个人正在互损，一个说另一个脑子有问题，一个说那人基本上就根本不会使用数据库。我往上翻了翻，起因是存储过程引起的，一个说自己的程序里面大多使用存储过程，会提高程序的效率，一个反唇相讥，说没有那个大型的应用会使用大量的存储过程替代程序。

由于谁都说服不了谁，所以就已经到了不是知识层面的互通，纯属人体方面的“交流”。

用不用存储过程要看情况 ！！  我手指不听使唤的打出的这几个字。 马上两个人安静了下来，一个马上回复，看什么情况，使用那么多存储过程就是性能底下。

我问了那人一句，如果存储过程性能低下，那你如何解释如下问题

1 针对复杂的SQL ，存储过程执行的性能比即系的SQL 要好，因为存储过程在创建时已经在内存中保留了一份，执行同样的存储过程，比每次都要执行复杂的SQL 要性能更好

2 如果程序仅仅是调用存储过程，那每次就不用发送复杂的SQL语句，这样其实对网络传输也是有好处的

3 存储过程比程序有更好的快速更改优势，便于快速处理问题

我说完这三点，另一个人马上说就是就是，程序就应该多用存储过程，来解决复杂的问题。

哎，我敲了这个字。

支持存储过程的那个人，问，你哎什么，

我说我在问你三个问题

1 SQL 本身是一个结构化查询语句，不是面向对象的语言，和JAVA,或者 C#不一样，可以处理复杂的事情，如果复杂的事情都用SQL 去处理，那SQL 写的会很复杂，很复杂的SQL 会造成各种BLOCKED  , DEAD LOCK，你希望这样吗

2 如果你并行运行存储过程，并且存储过程是比较复杂的，那你这样恰恰加重了数据库的负担，程序可以并发，但数据库在执行同一个操作，并发恰恰是弱项，各种锁，尤其SQL SERVER  表， 页 ，行，锁，且不说SQL SERVER 还有独有的 esclate，性能消耗更大

3 如果你大量使用临时表，在存储过程中，那你可能又要面临TEMP库增大，I/O压力等等的问题。

那你有什么高见？？  一个人问到

我答道， 首先你要分清楚你的SQL执行的频率有多大，如果你的系统比较繁忙，那你彻底就忘记存储过程这档子事情吧，少有高并发访问的数据库使用存储过程，作为解决方案的，大多都是程序那边去做计算，合并，缓存，也就是说，将大多数存储过程中的计算，迁移到程序端去做，而留给数据库的就是容器的概念，甚至某些大量的UPDATE操作，都要用REDIS 来处理，最后将结果写入到 数据库。

那个不支持存储过程的人，马上说道，你看吧，存储过程就是有问题吧

我问到，如果一个OLAP的系统要处理一个复杂的事情，也要用程序处理吗？ 不考虑存储过程吗？ 存储过程可以很好的解决OLAP的问题和批量的问题，并且某些OLTP的问题也可以在，时间紧，压力大，的情况下，迅速将软件的架构搭建起来。

你到底什么意见，到底是支持存储过程，还是程序来处理，给个准注意？？

看数据量级大小，和你是否需求并发，如果是前者，那我不建议，如果是后者还是可以的，但也要有度。

试想下图如果每个应用都要高频率使用存储过程，去调用同一个数据库某几张固定的表，那估计就是灾难性的，

其实群里两位，无非就是在争论，是让程序去承担更多的计算，和处理任务，将数据库作为一个容器 ，还是让程序更简单，将计算和数据整合放在数据库上。作为传统的解决方案，并且在数据量较少，访问量较少的情况下，其实使用存储过程，是一个比较省时省力快速的解决方案，反过来如果是高频，的OLTP系统，则高频率使用存储过程就值得商榷了。

这里借用 MICROSOFT 官方文档的中关于存储过程的介绍，其中的一句

“如果存储过程只需要处理一行，则使用本机编译存储过程没有任何性能优势”

另外根据微软官方提示，如果想使用高效的存储过程调用，（带参数），请不要使用命名参数，而使用序数@1  @2 这类看似无意义的传参，才更有利于存储过程的性能。

估计这个话题，还会继续讨论下去.......