前言

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

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

系统情况

　　硬件配置

　　软件情况

　　数据库情况

　　系统情况可以看出，这是一个较小型的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中隐式转换的一些细节浅析

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