优化的大招，你也能轻松掌握

今年正式干工还不到2个月，老虎刘已经给3家移动公司和两家银行做了优化，动作快的客户已经把优化建议基本实施完了。这些客户和他们的开发商中应该也有人关注着我这个公众号，如果系统性能有很大提升，点个赞就行。如果效果一般，一定要留言让大家知道。

这些系统的优化有一些方法我在之前的公众号文章里面都有介绍，比如在判断记录有无的时候（而不是返回具体的记录数），我们可以增加一个and rownum=1的谓词条件；还有避免使用select xxx from dual等。

今天介绍的大招就是我在前面优化中的5个系统中遇到的两个，都是消耗CPU的大户，在CPU的top sql排名中遥遥领先，有截图为证：

case1：这个top 1差不多是其余top 9的cpu之和

case2：下面这个为啥圈了两个top？因为top1的一个procedure，top2就是这个procedure里面的sql，我们只需要计算和分析top 2 sql就行了。这个top 1差不多也是其余top sql的cpu消耗之和

case1的sql是这样的：

select nvl(count(*) , 0) from xxx_table where mod(contract_no, 5)=:b1;

非常简单的sql，通过创建表上的函数索引，再加上一个rownum=1的谓词条件，这个sql的平均buffer gets数由67降到2（sql中的nvl函数也可以去掉，这个也能节省微量cpu资源。很多时候cpu资源就是这样一点点被浪费的），性能提升了33.5倍。但是，如果没有跟开发人员的沟通，这个优化对整个系统性能的提升没有一点意义：因为这个sql是循环执行的，原来每天执行4000万次，预计优化后执行次数将会是4000万*33.5次/天。实际上每天没有那么多的记录需要处理，这个sql大部分时间是一个空耗cpu的存在，而且业务处理也没有那么紧迫，两次执行时间间隔个1到2秒也是可以完全满足业务需求的。（开发人员也注意到了这个问题，正准备修改）。

我们假定每次循环只增加sleep 1秒的间隔，那么每天最多执行86400次，5个并发就是43万次，比原来4000万次有将近100倍 的降低，再加上执行效率33.5倍的提升，这个sql就会从原来遥遥领先的top 1，变得“泯然众人矣”，cpu消耗基本上可以忽略不计了。

对于case2，是存储过程的一个游标，sql业务逻辑非常复杂，每次执行消耗资源较多，从sql角度很难优化，老虎刘给开出的处方是降低该游标sql的执行频率：降低并发数，增加sql执行间隔时间；或者先需要处理的记录先存入临时表，游标访问临时表。

经过上面两个案例的分享，今天的优化大招就是：降低SQL的执行频率。

这个大招不需要什么优化技巧，相信一般的程序员都能轻松搞定。当然，前提还是要满足业务的实时性要求。