最近连续接触了4个OA系统，均存在着不同的性能问题，本文记述对某移动OA系统的优化全过程，让看官们对数据库优化流程有一个了解，并揭开隐式转换这无情杀手的神秘面纱。
本文使用的工具：SQL专家云平台专业体检工具 ：
系统情况硬件配置
软件情况
数据库情况
系统情况可以看出，这是一个较小型的OA系统数据大小70G，硬件配置较为普通2路16CPU、48G内存，数据库为2008R2版本。
数据库指标我们来看一下数据库的性能相关情况：数据是从早上九点半到晚上8点的数据
每秒请求数：
用户连接数
慢语句数量
系统等待情况
等待时间
CPU、内存、磁盘指标一切正常，还有很多指标，这里就不贴图了。
其实看到这里，大多数看官可以得出结论，硬件指标正常，阻塞这么严重，系统的慢主要是因为阻塞！并且语句运行时间长也是因为阻塞的时间长！
我的猜测
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.程序定义字段类型与表定义不相符（优先级高于表定义类型），直接修改参数设定类型
相关文章
精彩导读
热门资讯
关注我们
