性能優化實戰案例——助力某移動OA系統

前言

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

　　但咱們經過工具很清楚的分析出「隱式轉換」

　　

　　

 

　　在以前的表定義中，咱們能夠看出表的字段類型爲varchar，而傳入的參數是nvarchar（從隱式轉換的提示中得知）

　　

 

　　支持一個簡單的問題獲得定位，解決起來也是很是容易的，下面給出幾個隱式轉換的常看法決方式：

　　1.程序定義字段類型與表定義不相符（優先級高於表定義類型），直接修改參數設定類型

　　2.程序沒有定義類型好比java程序定義string ，而驅動自動翻譯成nvarchar ，這樣通常能夠在程序加入強制轉換 如 「where a = @a 」 改寫成 「where a = cast（@a as varchar（自定義長度））」

　　3.程序若是很難修改，或第三方開發，能夠直接修改表字段類型 

性能對比

　　通過1天的簡單優化程序性能獲得明顯改善

　　優化前

　　

　　優化後

　　

 

　　優化前

　　

　　優化後

　　

 

--------------博客地址---------------------------------------------------------------------------------------

博客地址 http://www.cnblogs.com/double-K/

 

 歡迎轉載，請註明出處，謝謝！

-----------------------------------------------------------------------------------------------------

 

　　總結 ： 文章只是簡單的描述了一下某移動公司OA優化的過程，主要講述了隱式轉換部分的發現與處理，其餘部分的優化都是常見手段請參見其餘文章。

　　　　SQL SERVER全面優化-------Expert for SQL Server 診斷系列

　　

　　　　關於隱式轉換的文章：SQL SERVER中隱式轉換的一些細節淺析

 ----------------------------------------------------------------------------------------------------

注：此文章爲原創，歡迎轉載，請在文章頁面明顯位置給出此文連接！
若您以爲這篇文章還不錯請點擊下右下角的推薦，很是感謝！