性能优化实战案例——助力某移动OA系统

Posted 2020-08-28

系统情况

　　硬件配置

　　

　　

　　软件情况

　　

 

　　数据库情况

　　

 

　　系统情况可以看出，这是一个较小型的OA系统数据大小70G，硬件配置较为普通2路16CPU、48G内存，数据库为2008R2版本。

数据库指标

　　我们来看一下数据库的性能相关情况：数据是从早上九点半到晚上8点的数据

　　每秒请求数：

　　

　　用户连接数

　　

　　慢语句数量

　　

　　系统等待情况

　　

　　等待时间

　　

　　

　　CPU、内存、磁盘指标一切正常，还有很多指标，这里就不贴图了www.qwangxiao.com。

　　其实看到这里，大多数看官可以得出结论，硬件指标正常，阻塞这么严重，系统的慢主要是因为阻塞！并且语句运行时间长也是因为阻塞的时间长！

 

　　我的猜测

　　OK 没问题就是这样的定位，同样我们看到大量的阻塞类型是LCK_M_IS、LCK_M_S、LCK_M_U ·····有了这样的定位，我可以猜测到，系统中一定有update语句不优化或太过频繁（OA这样的系统一般不会特别频繁，所以一定是不优化），而且设计核心的查询语句经常被阻塞（如果不是核心功能慢，用户也不会这样大叫！），而且80%的可能这部分核心查询也不够优化！

 

问题诊断

　　带着我的猜测我们看一下核心的一些语句：

　　

 

 

　　很多语句都类似，看到这样的简单语句（都是基本的查询几个字段一个where条件），我就知道问题其实一定很简单！

　　如此简单的语句设计那么跑出来是多长时间呢？

　　

 

　　很多人想到着一定是缺失索引，这样关键的where 条件上没有索引！！！！！

　　看一下结构：

　　

 

 　　

 

 

　　这个表是一个有280万数据的表，而不是像我们想象的那样缺失索引，相反where字段上的条件是一个聚集索引！！（其实如果只是条件单纯的缺失索引，技术人员怎么可能发现不了？）

 

　　整个系统其他问题不大，也就是说明，系统经过优化，程序设计的也很好，没有那种非常复杂的SQL，都是拆成一步一步很简单SQL，也就是说明这其中的技术人员水平还是很可以的！

　　那么问题来了，这是啥问题导致的？

　　可能出现的情况是：

　　1.我这条简单语句不缺少索引，而且单独在数据库跑很快很快（这是一定的）

　　2.我系统中阻塞的这么严重，是不是有什么地方我没发现？怎么这样的语句会阻塞的这么狠？

　　3.是不是我服务器有什么问题了？

　　

　　在创意粘性的一本书中写到“指挥官意图”相关，其中有一个比喻就和这个很接近，如果排除其他干扰，就只是看这样简单的语句为什么慢？这样我们就是意图明确，排除干扰，很快我们就会想到“隐式转换”导致索引不能使用的情况，但是正是因为上面的一些问题干扰，我们可能会被引导到，是不是服务器的问题，是不是阻塞情况我们有分析清呢？没有太多办法，数据库本身就是这样一个复杂的东西，各种因素的组合排查是最考验从业者的智慧的。

 

　　回到正题，“隐式转换”确实是一个写程序的人员很难发现的东西，因为我写出的语句很快，到数据库跑的时候慢，这我可不知道。

　　如果不知道什么是隐式转换，请参见：SQL SERVER中隐式转换的一些细节浅析

　　但我们通过工具很清楚的分析出“隐式转换”

　　

　　

 

　　在之前的表定义中，我们可以看出表的字段类型为varchar，而传入的参数是nvarchar（从隐式转换的提示中得知）

　　

 

　　支持一个简单的问题得到定位，解决起来也是非常容易的，下面给出几个隐式转换的常见解决方式：

　　1.程序定义字段类型与表定义不相符（优先级高于表定义类型），直接修改参数设定类型

　　2.程序没有定义类型比如java程序定义string ，而驱动自动翻译成nvarchar ，这样一般可以在程序加入强制转换 如 “where a = @a ” 改写成 “where a = cast（@a as varchar（自定义长度））”

　　3.程序如果很难修改，或第三方开发，可以直接修改表字段类型 

性能对比

　　经过1天的简单优化程序性能得到明显改善

　　优化前

　　

　　优化后

　　

 

　　优化前

　　

　　优化后