前言

　　最近連續接觸了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中隱式轉換的一些細節淺析

　　但我們通過工具很清楚的分析出“隱式轉換”