現在很多使用者被資料庫的慢的問題所困擾，又苦于花錢請一個專業的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（取消語句并行，要慎重真的符合你的場景才好）
注：很多時候并行度設定和你的伺服器CPU配置有關，比如有幾路、幾核、是否超線程，一般來說不要跨實體CPU為好。
并行開銷的閥值，主要控制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消耗以及運作時間，或者由自己的監控工具得到。
找到對應的時間點看看到底是什麼語句在運作~
對這條語句進行分析到底是為什麼！
CPU 真高
經過各種分析優化，如果依然CPU壓力明顯，真心是硬體不能支撐業務了，那麼我們就要選擇更高大上的方式了，比如修改程式設計垂直/水準拆分，新增硬體，讀寫分離分擔壓力，組建叢集負載均衡等等手段......
-----------------------------------------------------------------------------------------------------
總結：對于CPU壓力的解決，大部分的使用者可以通過調整并行度和系統語句的優化來解決。
另外對系統的監控和分析在診斷問題及解決問題中起到至關重要的作用。
在下結論前一定要經過仔細的分析研究，一個想當然的決定可能造成嚴重的影響。
你的系統真的需要加硬體，或高大上的方案麼？
-----------------------給出一些CPU相關的文章連接配接-----------------------------------------------------
桦仔的
SQLSERVER排查CPU占用高的情況高大俠的
深入解析SQL Server并行執行原理及實踐(下)careyson的 談一談SQL Server中的執行計劃緩存（上）
常用 監控SQLSERVER性能計數器
----------------------------------------------------------------------------------------------------
注：此文章為原創，歡迎轉載，請在文章頁面明顯位置給出此文連結！
若您覺得這篇文章還不錯請點選下右下角的推薦，非常感謝！
引用高大俠的一句話 ：“拒絕SQL Server背鍋，從我做起!”
為了友善閱讀給出系列文章的導讀連結：