近年来连日接触了4个OA系统

前言

  最近连续接触了4个OA系统,均存在着不同的性能问题,本文记述对某移动OA系统的优化全过程,让看官们对数据库优化流程有一个了解,并揭开隐式转换这无情杀手的神秘面纱。

  本文使用的工具:SQL专家云平台专业体检工具 :www.zhuancloud.com

系统情况

  硬件配置

  图片 1

  

  软件情况

  图片 2

 

  数据库情况

  图片 3

 

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

数据库指标

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

  每秒请求数:

  图片 4

  用户连接数

  图片 5

  慢语句数量

  图片 6

  系统等待情况

  图片 7

  等待时间

  图片 8

  

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

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

 

  我的猜测

  OK
没问题就是这样的定位,同样我们看到大量的阻塞类型是LCK_M_IS、LCK_M_S、LCK_  近年来连日接触了4个OA系统。M_U
·····有了这样的定位,我可以猜测到,系统中一定有update语句不优化或太过频繁(OA这样的系统一般不会特别频繁,所以一定是不优化),而且设计核心的查询语句经常被阻塞(如果不是核心功能慢,用户也不会这样大叫!),而且80%的可能这部分核心查询也不够优化!

 

问题诊断

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

  图片 9

图片 10

图片 11

图片 12

 

 

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

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

  图片 13

  近年来连日接触了4个OA系统。 

  近年来连日接触了4个OA系统。  很多人想到着一定是缺失索引,这样关键的where 条件上没有索引!!!!!

  看一下结构:

  图片 14

 

   图片 15

 

 

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

 

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

  那么问题来了,这是啥问题导致的?

  可能出现的情况是:

  近年来连日接触了4个OA系统。  近年来连日接触了4个OA系统。  1.我这条简单语句不缺少索引,而且单独在数据库跑很快很快(这是一定的)

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

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

  

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

 

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

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

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

  图片 16

  图片 17

 

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

  图片 14

 

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

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

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

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

性能对比

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

  优化前

  图片 19

  优化后

  图片 20

 

  优化前

  图片 21

  优化后

  图片 22

 

————–博客地址—————————————————————————————

博客地址 

 

 欢迎转载,请注明出处,谢谢!


 

  总结 :
文章只是简单的描述了一下某移动公司OA优化的过程,主要讲述了隐式转换部分的发现与处理,其他部分的优化都是常见手段请参见其他文章。

    SQL SERVER全面优化——-Expert for SQL Server
诊断系列

  

    关于隐式转换的文章:SQL
SERVER中隐式转换的一些细节浅析

 —————————————————————————————————-

注:此文章为原创,欢迎转载,请在文章页面明显位置给出此文链接!
若您觉得这篇文章还不错请点击下右下角的推荐,非常感谢!

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注