現在很多用戶被數據庫的慢的問題所困擾，又苦於花錢請一個專業的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並行執行原理及實踐(下)
careyson的 談一談SQL Server中的執行計划緩存（上）
常用 監控SQLSERVER性能計數器
----------------------------------------------------------------------------------------------------
注：此文章為原創，歡迎轉載，請在文章頁面明顯位置給出此文鏈接！
若您覺得這篇文章還不錯請點擊下右下角的推薦，非常感謝！
引用高大俠的一句話 ：“拒絕SQL Server背鍋，從我做起!”
為了方便閱讀給出系列文章的導讀鏈接：