現在很多用戶被資料庫的慢的問題所困擾，又苦於花錢請一個專業的DBA成本太高。軟體維護人員對資料庫的瞭解又不是那麼深入，所以導致問題遲遲不能解決，或只能暫時解決不能得到根治。開發人員解決數據問題基本又是搜遍百度各種方法嘗試個遍，可能錯過診斷問題的最佳時機又可能嘗試一堆方法最後無奈放棄。怎麼樣讓瑣事纏 ...

　　　　現在很多用戶被資料庫的慢的問題所困擾，又苦於花錢請一個專業的DBA成本太高。軟體維護人員對資料庫的瞭解又不是那麼深入，所以導致問題遲遲不能解決，或只能暫時解決不能得到根治。開發人員解決數據問題基本又是搜遍百度各種方法嘗試個遍，可能錯過診斷問題的最佳時機又可能嘗試一堆方法最後無奈放棄。

　　　　怎麼樣讓瑣事纏身的程式維護人員，用最快的方式解決資料庫出現的問題？怎麼讓我們程式員的痛苦降低到最小...每天喝喝茶水，看看新聞平安度過一天呢？本系列重要通過Expert for sqlserver 工具講解下資料庫遇到的各種問題的表象及導致這樣問題的根本原因，讓定位問題更準確，解決問題思路更清晰！！

　　　　資料庫的性能好壞，對於最終用戶來說表現為點擊的操作是否能夠快速響應，那麼反應到資料庫上就是語句執行時間是否夠短！

　　　　對用運維人員資料庫性能的表現，簡單可能看成CPU 、記憶體、磁碟三巨頭指標是否正常，那麼今天我們就從CPU 下手，看看CPU能夠看出哪些問題！

廢話不多說，直接開整---------------------------------------------------------------------------------------------------

　　主要用到的性能計數器（不知道什麼是性能計數器的，請自行百度）

　　就用兩個~

%Process Time　全實例　（主要用於查看當前伺服器的CPU 情況）
%Process Time　sqlservr （主要用於查看資料庫使用的CPU情況）

排除其他應用影響CPU　　　　　　　　　　　　　　　　　　　　　　　

　　綜合這兩個計數器在同一時間點可以診斷出CPU 是否是被伺服器其他的應用所消耗的，如圖中17:10 左右的 “%Process Time　全實例（紅線）” 突然升高，而SQL 服務的（綠線）並無明顯升高，這也就說明，在這個時間段的CPU 壓力不是有資料庫導致的！

　　這個紅線的明顯升高時，因為我在資料庫所在的伺服器上做了一次文件壓縮！類似文件壓縮這種操作會使用大量CPU，對資料庫性能造成衝擊！

　CPU 問題分析　　　　　　　　　　　　　　　　　　　　　　　　

　　　CPU很高或者達到100%一定是你業務壓力很大？CPU 不能滿足你的需求麽？在下結論前請仔細分析，一個草率的定論可能換來，老闆一個安慰“世界那麼大你該出去走走了！”

　　　下麵我們用幾個典型的場景，分析下問題，並給出最佳實踐~

　　　高峰時段CPU 持續很高

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　圖中是伺服器幾天的CPU情況

　　　　很多人看到這張圖，是不是看到了自己的伺服器？是否有一種親切感呢~下麵我們來分析下這種表象可能存在的問題！

　　　　首先明確一點90%的問題可能集中在10%的場景，這種CPU 持續持續很高的情況請註意下麵兩點：

你的資料庫並行度是否調整？
你的資料庫是否缺少索引，導致頻繁的查詢消耗很高的CPU資源？

　　　　最大並行度是什麼？簡單的可以理解為執行一條語句最多可以使用多少個CPU。看起來當然是使用的越多越好啦，使用的越多語句肯定越快呀！這個答案是大寫的 “NO”，使用過多的CPU會導致線程協同工作產生的時間較長，直接導致語句很慢，而且消耗的CPU時間很多，導致CPU使用高，進而成為瓶頸！

　　看一個數據語句持續時間也就是執行時間，但是看看CPU的時間，這就是沒有設置並行度，一個並行計劃會產生大量的CPU消耗，另外會讓語句執行的更慢！　　　　

　　　　那麼是不是使用的越少越好呢？任何事情沒有絕對的，視情況而定，如果系統有比較大數據量的操作需求，並行使用多個CPU會有很大的提升。

　　　　一般建議系統如果超過32個CPU 那麼設置成8或者4，如果系統中都是特別短小且頻繁的語句建議設置成1（取消語句並行，要慎重真的符合你的場景才好）

　　　　並行開銷的閥值，主要控制SQL優化器何時選用並行計劃，建議預設值，此值設置的越小優化器越容易選擇並行計劃。

　　　　並行度的設置是針對實例級別的設置（2016中可以對單獨資料庫設置）

　　　　怎麼設置並行度和閥值，請看下圖: 系統預設的並行度為0，閥值預設為5

　　　　並行度的調整可謂誰用誰知道啊，下麵我們說說系統老大難的問題--語句導致CPU高

　　　　語句導致CPU高也是很常見的問題之一，那麼語句怎麼調優降低CPU 消耗呢？這裡只做一些簡單的說明，具體的語句調優、參數化減少語句編譯，請看後面的系列文章。

　　　　語句調優的方式很多種，這裡介紹和CPU相關最為常用：

添加索引降低語句開銷，執行需要的資源消耗少了消耗的CPU 自然相對就少了。
降低語句複雜度，讓SQL Server執行高效（同樣也是降低資源消耗的方法）。
分析語句是否可以採用串列計劃。
前端程式儘量參數化減少語句的編譯消耗。

CPU 規律波動

　　　　拿到CPU的監控數據不要盲目下結論，數據往往是最能反映問題，給你提供思路的！

　　　　如果你是系統維護人員，看到類似這樣的CPU數據指標，如果你還不能有一些思路，請你好好熟悉下你親愛的系統。

　　　　這張圖很清晰地反映出系統每半小時一次的CPU升高，那麼別忙著去找對應時間點的語句，我們最少要好好想一下，系統中有什麼操作半小時執行一直？SQL JOB？計劃任務？前臺定時處理？等等等

　　　　這個規律的定時處理是否有異常？是否最近有什麼改動？執行的結果是不是和你想的一樣？

　　　　也許問題就這麼清晰的定位了......

CPU 突然飆高

　　　　　　　　　　　　　　　　　　　　圖中 9點CPU由平均20幾飆升到100%

　　　　CPU突然飆高可能是偶然的現象，也許你可以認為沒有關係，但當你判斷為偶然之前，你是否做過下麵的分析：

是否分析過系統日誌，CPU飆高時間點是否有異常？
是否檢查伺服器上有什麼特殊應用？
是否檢查了資料庫狀態？
是否詢問過相關業務人員？
是否馬上開啟監控為下一次突發情況的到來做好準備？

　　　　如果沒有你的判斷真是毫無根據...也錯過了一次發現問題，學習知識的機會！

　　　　排除上述異常，最有可能的原因就是資料庫中，在那一刻有一個或多個語句運行異常，或非常不優化。如果這情況真的因為語句問題，而且只出現一次，那麼這可能不是問題，我們儘量找到當時的語句，查看問題。找到當時的語句可以通過系統視圖sys.dm_exec_query_stats 查看CPU消耗以及運行時間，或者由自己的監控工具得到。

　　　　找到對應的時間點看看到底是什麼語句在運行~