程序猿是如何解決SQLServer佔CPU100%的
文章目錄
- 遇到的問題
- 有哪些SQL語句會致使CPU太高？
-
查看SQL的查詢計劃node
- 其餘優化手段
-
總結git
遇到的問題
有同事反應服務器CPU太高，一看截圖基本都是100%了，my god，這但是大問題，趕忙先看看。面試
讓同事查看系統進程，發現是SQLServer的CPU佔用比較高。首先想到的是否是報表生成的時候高，由於這塊以前出現過問題，關掉服務程序，仍是高。難道是客戶端程序引起的？可是這麼多的客戶端鏈接，難不成每一個都叫人關閉，很簡單，把網絡斷開便可。網絡斷開以後，CPU立馬降低。那麼問題到底在哪裏呢，是時候祭出咱們的利器了——SQLServer Profiler。算法
使用SQLServer Profiler監控數據庫
讓同事使用SQLProfiler監控了大概20分鐘左右，而後保存爲跟蹤文件*.rtc。sql
咱們來看看究竟是哪句SQL有問題：數據庫
SQL1：查找最新的30條告警事件
select top 30 a.orderno,a.AgentBm,a.AlarmTime,a.RemoveTime,c.Name as AddrName,b.Name as MgrObjName,a.Ch,a.Value,a.Content,a.Level ,ag.Name as AgentServerName,a.EventBm,a.MgrObjId,a.Id,a.Cfmoper,a.Cfm,a.Cfmtime,a.State,a.IgnoreStartTime,a.IgnoreEndTime ,a.OpUserId,d.Name as MgrObjTypeName,l.UserName as userName,f.Name as AddrName2 from eventlog as a left join mgrobj as b on a.MgrObjId=b.Id and a.AgentBm=b.AgentBm left join addrnode as c on b.AddrId=c.Id left join mgrobjtype as d on b.MgrObjTypeId=d.Id left join eventdir as e on a.EventBm=e.Bm left join agentserver as ag on a.AgentBm=ag.AgentBm left join loginUser as l on a.cfmoper=l.loginGuid left join addrnode as f on ag.AddrId=f.Id where ((MgrObjId in ( select Id from MgrObj where AddrId in ('','02100000','02113000','02113001','02113002','02113003','02113004' ,'02113005','02113006','02113007','02113008','02113009','02113010','02113011','02113012' ,'02113013','02113014','02113015','02113016','02113017','02113018','02113019','02113020' ,'02113021','02113022','02113023','02113024','02113025','02113026'))) or (mgrobjid in ('00000000-0000-0000-0000-000000000000','00000000-0000-0000-0000-000000000000' ,'00000000-0000-0000-0000-000000000000','11111111-1111-1111-1111-111111111111' ,'11111111-1111-1111-1111-111111111111')) ) order by alarmtime DESC
SQL2：獲取當前的總報警記錄數
select count(*) from eventlog as a left join mgrobj as b on a.MgrObjId=b.Id and a.AgentBm=b.AgentBm left join addrnode as c on b.AddrId=c.Id left join mgrobjtype as d on b.MgrObjTypeId=d.Id left join eventdir as e on a.EventBm=e.Bm where MgrObjId in ( select Id from MgrObj where AddrId in ('','02100000','02100001','02100002','02100003','02100004','02100005','02100006','02100007' ,'02100008','02100009','02100010','02100011','02100012','02100013','02100014','02100015' ,'02100016','02100017','02100018','02100019','02101000','02101001','02101002','02101003' ,'02101004','02101005','02101006','02101007','02101008','02101009','02101010','02101011','02101012' ,'02101013','02101014','02101015','02101016','02101017','02101018','02101019','02101020','02101021' ,'02101022','02101023','02101024','02101025','022000','022001','022101','022102','0755','0755002') ) and mgrobjid not in ( '00000000-0000-0000-0000-000000000000','00000000-0000-0000-0000-000000000000','00000000-0000-0000-0000-000000000000' ,'11111111-1111-1111-1111-111111111111','11111111-1111-1111-1111-111111111111')
這是典型的獲取數據並分頁的數據，一條獲取最新分頁記錄總數，一條獲取分頁記錄，正是獲取最新事件這裏致使的CPU太高。這裏的業務大概是每一個客戶端，每3秒執行一次數據庫查找，以便顯示最新的告警事件。好了，元兇找到了，怎麼解決？緩存
有哪些SQL語句會致使CPU太高？
上網查看了下文章，得出如下結論：服務器
1.編譯和重編譯微信
編譯是 Sql Server 爲指令生成執行計劃的過程。Sql Server 要分析指令要作的事情，分析它所要訪問的表格結構，也就是生成執行計劃的過程。這個過程主要是在作各類計算，因此CPU 使用比較集中的地方。
執行計劃生成後會被緩存在 內存中，以便重用。可是不是全部的均可以 被重用。在不少時候，因爲數據量發生了變化，或者數據結構發生了變化，一樣一句話執行，就要重編譯。
2.排序（sort） 和 聚合計算（aggregation）
在查詢的時候，常常會作 order by、distinct 這樣的操做，也會作 avg、sum、max、min 這樣的聚合計算，在數據已經被加載到內存後，就要使用CPU把這些計算作完。因此這些操做的語句CPU 使用量會多一些。
3.表格鏈接（Join）操做
當語句須要兩張表作鏈接的時候，SQLServer 經常會選擇 Nested Loop 或 Hash 算法。算法的完成要運行 CPU，因此 join 有時候也會帶來 CPU 使用比較集中的地方。
4.Count(*) 語句執行的過於頻繁
特別是對大表 Count() ，由於 Count() 後面若是沒有條件，或者條件用不上索引，都會引發 全表掃描的，也會引發 CPU 的大量運算
大體的緣由，咱們都知道了，可是具體到咱們上述的兩個SQL，好像都有上述提到的這些問題，那麼到底哪一個纔是最大的元兇，咱們可以怎麼優化？
查看SQL的查詢計劃
SQLServer的查詢計劃很清楚的告訴了咱們到底在哪一步消耗了最大的資源。咱們先來看看獲取top30的記錄：
排序居然佔了94%的資源。原來是它！同事立刻想到，用orderno排序會不會快點。先把上述語句在SQLServer中執行一遍，清掉緩存以後，大概是2~3秒，而後排序字段改成orderno，1秒都不到，果真有用。可是orderno的順序跟alarmTime的順序是不徹底一致的，orderno的排序沒法替代alarmTime排序，那麼怎麼辦？我想，由於選擇的是top，那麼由於orderno是彙集索引，那麼選擇前30條記錄，能夠當即返回，根本無需遍歷整個結果，那麼若是alarmTime是個索引字段，是否能夠加快排序？
選擇top記錄時，儘可能爲order子句的字段創建索引
先創建索引：
IF NOT EXISTS(SELECT * FROM sysindexes WHERE id=OBJECT_ID('eventlog') AND name='IX_eventlog_alarmTime') CREATE NONCLUSTERED INDEX IX_eventlog_alarmTime ON dbo.eventlog(AlarmTime)
在查看執行計劃：
看到沒有，剛纔查詢耗時的Sort已經消失不見了，那麼怎麼驗證它可以有效的下降咱們的CPU呢，難道要到現場部署，固然不是。
查看SQL語句CPU高的語句
SELECT TOP 10 TEXT AS 'SQL Statement' ,last_execution_time AS 'Last Execution Time' ,(total_logical_reads + total_physical_reads + total_logical_writes) / execution_count AS [Average IO] ,(total_worker_time / execution_count) / 1000000.0 AS [Average CPU Time (sec)] ,(total_elapsed_time / execution_count) / 1000000.0 AS [Average Elapsed Time (sec)] ,execution_count AS "Execution Count",qs.total_physical_reads,qs.total_logical_writes ,qp.query_plan AS "Query Plan" FROM sys.dm_exec_query_stats qs CROSS APPLY sys.dm_exec_sql_text(qs.plan_handle) st CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp ORDER BY total_elapsed_time / execution_count DESC
咱們把建索引先後CPU作個對比：
已經明顯減低了。
經過創建相關索引來減小表掃描
咱們再來看看count(*)這句怎麼優化，由於上面的這句跟count這句差異就在於order by的排序。老規矩，用查詢計劃看看。
用語句select count(0) from eventlog一看，該表已經有20多w的記錄，每次查詢30條數據，居然要遍歷這個20多w的表兩次，能不耗CPU嗎。咱們看看是否可以利用相關的條件來減小表掃描。很明顯，咱們能夠爲MgrObjId創建索引：
CREATE NONCLUSTERED INDEX IX_eventlog_moid ON dbo.eventlog(MgrObjId)
可是不管我怎麼試，都是沒有利用到索引，難道IN子句和NOT IN子句是無法利用索引必定會引發表掃描。因而上網查資料，找到樺仔的文章，這裏面有解答：
SQLSERVER對篩選條件（search argument/SARG）的寫法有必定的建議
對於不使用SARG運算符的表達式，索引是沒有用的，SQLSERVER對它們很難使用比較優化的作法。非SARG運算符包括
NOT、<>、NOT EXISTS、NOT IN、NOT LIKE和內部函數，例如：Convert、Upper等
可是這偏偏說明了IN是能夠創建索引的啊。百思不得其解，通過一番的諮詢以後，獲得瞭解答：
不必定是利用索引就是好的,sqlserver根據你的查詢的字段的重複值的佔比，決定是表掃描仍是索引掃描
有道理，可是我查看了下，重複值並不高，怎麼會有問題呢。
關鍵是，你select的字段，這個地方使用索引那麼性能更差，你select字段 id,addrid,agentbm,mgrobjtypeid,name都不在索引裏。
真是一語驚醒夢中人，缺的是包含索引！！！關於包含索引的重要性我在這篇文章《我是如何在SQLServer中處理天天四億三千萬記錄的》已經提到過了，沒想到在這裏又從新栽了個跟頭。實踐，真的是過重要了！
經過創建包含索引來讓SQL語句走索引
好吧，立馬創建相關索引：
IF NOT EXISTS(SELECT * FROM sysindexes WHERE id=OBJECT_ID('eventlog') AND name='IX_eventlog_moid') CREATE NONCLUSTERED INDEX IX_eventlog_moid ON dbo.eventlog(MgrObjId) INCLUDE(EventBm,AgentBM)
咱們再來看看查詢計劃：
看到沒有，已經沒有eventlog表的表掃描了。咱們再來比較先後的CPU：
很明顯，這個count的優化，對查詢top的語句依然的生效的。目前爲止，這兩個查詢用上去以後，再也沒有CPU太高的現象了。
其餘優化手段
- 經過服務端的推送，有事件告警或者解除過來才查詢數據庫。
- 優化上述查詢語句，好比count(*)能夠用count(0)替代——參考《SQL開發技巧(二)》
- 優化語句，先查詢出全部的MgrObjId，而後在作鏈接
- 爲管理對象、地點表等增長索引
- 添加了索引以後，事件表的插入就會慢，可以再怎麼優化呢？能夠分區創建索引，天天不忙的時候，把新的記錄移入到建好索引的分區
固然，這些優化的手段是後續的事情了，我要作的事情基本完了。
總結
- 服務器CPU太高，首先查看系統進程，肯定引起CPU太高的進程
- 經過SQLServer Profiler可以輕易監控到哪些SQL語句執行時間過長，消耗最多的CPU
- 經過SQL語句是能夠查看每條SQL語句消耗的CPU是多少
- 致使CPU高的都是進行大量計算的語句：包括內存排序、表掃描、編譯計劃等。
- 若是使用Top刷選前面幾條語句，則儘可能爲Order By子句創建索引，這樣能夠減小對全部的刷選結果進行排序
- 使用Count查詢記錄數時，儘可能經過爲where字句的相關字段創建索引以減小表掃描。若是多個表進行join操做，則把相關的錶鏈接字段創建在包含索引中
- 經過服務端通知的方式，減小SQL語句的查詢
- 經過表分區，儘可能下降由於添加索引而致使表插入較慢的影響
參考文章
- SQLSERVR語句 in和exists哪一個效率高本人測試證實
- Sql Server Cpu 100% 的常見緣由及優化
- SQLSERVER排查CPU佔用高的狀況
- 人人都是 DBA（XII）查詢信息收集腳本彙編
最後，感謝博客園DBA樺仔的熱心指點。
若是您以爲閱讀本文對您有幫助，請點一下「推薦」按鈕，您的「推薦」將是我最大的寫做動力！ 若是您想持續關注個人文章，請掃描二維碼，關注馬非碼的微信公衆號，我會將個人文章推送給您，並和您一塊兒分享我平常閱讀過的優質文章。
本文版權歸做者和博客園共有，來源網址：http://www.cnblogs.com/marvin/ 歡迎各位轉載，可是未經做者本人贊成，轉載文章以後必須在文章頁面明顯位置給出做者和原文鏈接，不然保留追究法律責任的權利。