浅谈系统优化设计--复杂运算放在逻辑层还是在数据库层？

     前段时间，我们去回访客户，看了今年上半年优化的一个系统，看看性能怎么样。去了以后，客户反映感觉还可以，不慢，就是说这段时间数据库服务器的CPU有时超过了90%，会持续一段比较长的时间，可能有几十分钟。

     下午，就发现这时候数据库服务器的CPU一直在90%以上。通过sql server profile也没查出什么问题。觉得操作很正常，后来通过DMVs发现，执行我以前改写的几个存储过程，执行次数比较多，但是估计前台调用很频繁。

    后来通过他们的联系和交流，结果是：有不少业务人员在操作完数据后，再去查一次我以前写那几个对账存储过程（最多超过450行）调数据。

    这里介绍一下对账存储过程：

       以前因为将对账逻辑封装在JBOSS应用层，当时发现查询速度慢，一旦查询的人多，jboss的cpu就一直是100%，业务无法操作，但数据库服务器还好。后来我就将其全部逻辑封装在数据库层（4个存储过程，3个函数），速度比以前大大提高。

     注： 这里的对账有好几个角度，所以有4个存储过程。

    分析结果：      

       业务人员大量调用对账存储过程进行复杂计算

      开始我跟客户讲：这里的对账，是比较复杂的逻辑计算，是比较耗CPU的，一般使用的比较少，

       一个业务人员一个月查一次都不错了，而现在是下面10多人在持续调用。所以数据库服务器CPU一直在90%以上，但幸运的是客户的系统并没因为90%而引起速度慢或者是Down机情况，业务正常运行。

      经过这件事，我一直在想，复杂逻辑计算是放在逻辑层还是放在数据库层好啊？

   查了一下资料，解决复杂逻辑有：

         1，建立同步数据库，将读和写分离。(使用比较多） 如：淘宝网        

         2，将复杂逻辑计算放在逻辑层，当然SQL语句是经过优化过的（在逻辑层做集群服务，分成多台应用服务器JBOSS): 如 ebay   

     当然上面两个方法都有他的好处，看大家怎么使用了。我个人倾向第一种，将业务逻辑放在数据库层，也正如Tom在《Oracle 高效设计》提倡的尽量使用数据库来提高性能。