【IT168 专稿】今天，企业信息系统的绝大部分应用都属于数据库应用，数据库系统可以说是企业信息系统的核心。在数据库系统的实际应用环境中，我们经常会遇到访问量、带宽等瓶颈，影响数据库系统的整体运行效率，因此我们常常会寻求各种优化系统的方法。

    但是在笔者工作经验中，常常看见一些企业没有弄清楚自己的业务类型到底是什么，搞不清楚自身系统的瓶颈究竟在哪里，就开始盲目的寻求系统优化的方法，结果不但对系统性能没有任何的提高，甚至可能带来适得其反的效果。

    因此，在进行系统优化之前，搞清楚自己的业务类型是非常重要的，只有确定清除自身的业务类型后，才有可能对症下药对系统进行优化。一般而言，数据库系统的类型通常包括两种类型：OLTP和OLAP。

OLTP对服务器CPU的影响

    OLTP，也叫联机事务处理(Online Transaction Processing)，表示事务性非常高的系统，一般都是高可用的在线系统，以小的事务以及小的查询为主。在评估其系统的时候，一般看其每秒执行的transaction以及execute sql的数量。

    在这样的系统中，每秒处理的transaction往往超过几百个，或者是几千个，select 语句的执行量每秒几千甚至几万个。典型的OLTP系统如电子商务系统，银行，证卷等等，如美国ebay的业务数据库，就是很典型的OLTP数据库。

    OLTP系统最容易出现的瓶颈就是服务器系统的CPU与磁盘子系统。

    CPU的损耗取决于逻辑读以及内部调用的执行频度，如函数等等。对于这种类型的损耗，最有效的优化措施是对数据库语句做一定的优化。

    例如，一个执行频繁的SQL语句，即使每个语句只减少了很少的逻辑读，也相当于优化了逻辑读很差的大型语句，对整体系统性能能有较大的提高。很多人似乎感觉不到这里的作用，觉得一个语句几十个逻辑读，执行时间基本为0，就不需要优化了。其实，只要他的执行的频次非常频繁，而且有优化的余地，就一定要优化。减少一定的逻辑读或者降低执行次数，都是有效的优化方法。

    此外，数据库系统中一些计算性的函数，如sum，count，decode被非常频繁的使用，也会产生相当大的CPU损耗，笔者就曾经遇到一个系统，因为一个sql语句，大量的使用了sum与decode进行行列转换，结果这一个语句就耗费了整个机器一半以上的CPU。

    在一般的OLTP系统中，如果不考虑笔者上面所说的函数问题，那么，逻辑读乘以执行次数，就决定了cpu的消耗程度。

    比如一个语句，每秒执行次数为500次，每个逻辑读为15，但是，通过优化，能让每个语句的逻辑读从15降到10，那么，每秒的逻辑读就可以减少500*5=2500个，其实就是相当于优化了一个执行频率为每秒1次，每次逻辑读为2500个的语句（注意，2500个逻辑读，在OLTP系统中是非常差的语句）。

    再比如，我们假定一个1GHZ的cpu每秒能正常处理的逻辑读是100,000个，假定每个语句都包括10个逻辑读，那么这样的语句CPU每秒可以处理10,000个，而1000个逻辑读一个的语句，每秒则只能处理100个。很显然前一种情况相比后一种情况速度提升很多，因此整体系统的运行效率能够大幅度的提高。而当我们确定数据库的逻辑读速度后，我们也可以根据数据库的运行负荷来选择或者扩充服务器CPU。