Expert 診斷優化系列------------------你的CPU高麼？
現在很多使用者被資料庫的慢的問題所困擾，又苦於花錢請一個專業的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相關的文章連線-----------------------------------------------------
----------------------------------------------------------------------------------------------------
注：此文章為原創，歡迎轉載，請在文章頁面明顯位置給出此文連結！
若您覺得這篇文章還不錯請點選下右下角的推薦，非常感謝！
引用高大俠的一句話 ：“拒絕SQL Server背鍋，從我做起!”
為了方便閱讀給出系列文章的導讀連結：