只改2条语句，治好HIS系统数据库“葛优瘫”！(2)

• 优化后

• 优化前

• 优化后

再次分析解决大面积语句阻塞的系统,发现现在的情况,主要有如下几个：

再次对系统调研：

调研后,我遇到了最常见也是最大的问题： 语句慢由于程序!很多人看到这会说程序慢就改呗,那有啥问题? 问题就在于你来做优化直接了当的和人家开发人员说你程序太烂必须改!如果你是程序开发人员你会有什么样的反应?

他会说：对不起,影响太大改不了!

那么这个优化项目黄了,或者你要付出更大的代价绕过这样的问题.

分析中发现程序使用了大量各种自定义函数,有一定经验的人都应该知道,语句在筛选的列上使用函数是没有办法使用索引查找的,这样相对于这种单表数据就几百甚至几千万的表,是何等的灾难!但是不能冒然突出修改程序,那还能怎么优化呢?大概分析后得出结论,程序主要消耗在几部分：

• 针对第一部分在不能改程序的情况下,尝试添加计划向导改变语句执行情况；
• 针对第二部分修改接口视图,包括替换掉函数、添加索引等；
• 针对第三部分报表这东西不是短期就可以优化的,所以再原有镜像的方案上添加快照,实现了简单的读写分离,直接分走；

语句优化的效果：

• 优化前

• 优化后

• 优化前

• 优化后

经过前两个阶段的优化一般系都会明显好转,并且指标正常,这也是前面提到的可以慢的地方慢已经解决,那么为什么CPU、内存压力没有缓解?难道真的是64CPU、128G内存不能支持了?需要加内存换CPU?难道要做负载均衡?各种拆分?

• CPU分析

首先我对CPU压力进行了分析,综合语句的CPU消耗和CPU的表象来看,很大一部分应该不是语句执行消耗的!那么服务器上确实也没有跑其他程序,CPU资源哪里去了?

看看这个计数器：

SQL的编译次数高峰时间段达到每秒2000多次!很多书上写过,相信很多看官也知道,语句不参数化会给CPU造成压力,这就是个鲜活的例子!那么解决办法也是比较粗暴,程序无法修改那么就在数据库上开启强制参数化.

看下效果：

我想不用多说什么了!

• 内存分析

看到了CPU的现象那么内存的问题也有眉目了,这么多编译即席查询,首先看一下内存中缓存了那些数据：

（编辑：ASP站长网）