基本情况： G!QwJe9Gk  
x:zO
RJQ  
    系统是一个基于web的业务系统，以online查询为主，数据更新以批量为主，晚上执行。应该说系统还不算负载太大。5-1之后上班的时候客户反映很慢，察看DB的cpu慢慢长到100%状态。服务基本处于不可用状态。i/o wait也挺高的。 xn<qC&x0e  
    经检查，前些天的批量竟然有达到20多小时才完成，导致次日批量都跑不起来。 T 9>1  
    -6$@BosVA  
    打开statspack收集信息 b8xmmsj#  
    af`QKI:v^  
    从系统中发现本应该夜间执行的批量作业还在运行。停掉后，rollback做了4个小时！（因为一个transaction中只有一个复杂的、数据量巨大的insert语句) L5MSfg1KY  
    ivMe-cUT  
    然后做statspack分析， W{ZEQ Ef  
    .,k Vl3  
    系统中存在问题:等待事件较严重,缓存命中率较低, I:#*\rp  
    n]WJ Ei  
    语句分析： :W&gA{F>  
~^`5X?z  
    1、一些大量执行update/delete语句竟然没有建立索引，其实可以建立pk，根据pk处理。 8kVZhjb[e  
a&*k )y  
    where中使用常量(引起parse) I,SxOz~l  
    2N`2G $FR  
    2、存在大量这样的语句： GyTAY^kD  
)%CM8\=#'  
    SELECT fieldx FROM Tablesname where trim(ServiceNUM) = 'DDDDDD' P{KrCdFwe  
    - 在ServiceNUM字段上是唯一索引，因为trim就不能使用index(败笔) --改！ hOnl=?   
    - 使用常量查询，造成每次查询都要parse，没有必要的占用的CPU -- 改！ M0k_lt  
    Qp:eb f  
    4.Pg%je3V  
    3、在批量的存储过程中， Dz!T> Lr  
T}nQ4 ^hU  
    所有语句基本都是全表扫描！ --- 和开发人员沟通，需要修改逻辑。改进之后效果还是蛮大的。 kx_du
Fp|  
    z\
~1Q7  
    另外发现一个问题： )]e~>mNlvc  
a#@b [=s~  
    客户需要的是n百万用户数据中的活动用户万数据，他们却全部把n百万数据从其他系统中收集到自己的系统中，在批量的时候又使用full table scan，性能自然不会好。系统从刚开始设计的时候就存在隐患。这个问题就需要从长计议了。 ?s}ph0N  
    '$Od2J _|  
    修改后，CPU高峰时间基本稳定在30-40%之间。 _advfhx!  
    批量基本在2个小时内完成。 XviuoQs_g  
    NSJ!eJA  
    其实是一个很简单的系统，但是做到这种样子，尤其是从设计到编码都存在问题。呵呵，说真的，不是在优化语句的，而是从头开始看设计。 K7+|2X