一次cpu的user比例过高的调优

近期遇一个省的数据库说总是繁忙，idle很小，在凌晨稍微跑几个比较大的统计脚本，idle就出现0的情况，导致业务发生堵塞。

经过连续几天的观察，发现cpu曲线大致如下：

2008年11月18日：

和白鳝交流了一下，老白说cpu的user%比例过高可能是由于buffer get比较高的sql引起。可以重点找一下statspack中buffer get比较高的语句。

根据sar出来的结果，查看对应时间段的statspack：

首先查了hash value为1460516408和2446775708的sql，因为这2个sql的执行次数不高，但是单次执行的消耗很高，查询后发现2个sql的consistent gets有47万。与开发沟通后，该sql的执行计划已经无法改变，但是由于是通过时间点触发，可以将该sql的执行时间延迟到6点之后执行。

同时hash value为3767922078之类的sql由于执行太过于频繁，要求该进程的执行频率是否能够降低一些？但是该进程由于涉及状态同步，如果降低频率会引起用户投诉，暂时无法处理该sql。

待调整后，继续观察一天。发现晚上的曲线还是大致相仿：

2008年11月19日：

继续观察对应时间段的statspack：

发现consistent gets很高的那几个sql已经不再出现，但是为何user的比例还是很高呢？

此时，突然发现了执行很频繁的几个sql，cpu time（s）有300多秒！！如hash value 3582277248、3767922078这几个sql的cpu time比昨天调整的consistent gets 还高！！

其实昨天查的时候，也注意过这几个sql，这几个sql虽然是走全表扫描，不过执行的速度很快：

buffer get部分中cpu time这么高，估计是这几个sql影响了。查询了一下该sql在别的省的执行计划，发现是走PK索引的。这个省的主键不知道被谁删除掉了！！

建立PK后，发现user一下子就下去了。

总结：遇到cpu的user高问题，如果没有enqueue，latch free之类的等待，仅仅是cpu time的等待，看statspack 中buffer get中的cpu time(s)高的sql很重要。