開始暴露問題
??? 2011年2月下旬的一天早上，昨天更新的系統(tǒng)，早上發(fā)現(xiàn)數(shù)據(jù)庫的服務(wù)器CPU達到100%，而且持續(xù)的時間很長，不得回到昨天更新前的版本，但系統(tǒng)還是有較長時間達到100%的情況，問題沒有解決，從這正式開始優(yōu)化線上數(shù)據(jù)庫性能。
?
第一階段優(yōu)化
?? 分析問題：
??? 一開始老是想找出問題的原因，找了3天還沒有頭緒，列出以下原因：
?? 1，JOB的耗時存儲過程? --太頻繁，執(zhí)行時間長，1,2分鐘
?? 2，頻繁執(zhí)行同樣的SQL? --如查詢用戶表sys_user 幾分鐘內(nèi)執(zhí)行數(shù)千次
?? 3，tempdb太小
?? 4，運行SQL太慢
?? 5，數(shù)據(jù)庫阻塞
???? 但這些原因，都找不出具體的在那塊有問題，好像都有，又好像都沒有，時間在一天天過去，但是系統(tǒng)還是100%經(jīng)常發(fā)生，嚴重影響業(yè)務(wù)使用，這時只能按照以前的優(yōu)化經(jīng)驗調(diào)整優(yōu)化思路，不找原因，只要是問題就優(yōu)化，一個一個處理，最終解決系統(tǒng)性能問題：
?主要是執(zhí)行優(yōu)化方法：
? 1，刪除全部的主鍵聚集索引，改成唯一非聚集索引
? 2，刪除重建全部索引
? 3，刪除全部外鍵約束
? 4，持續(xù)優(yōu)化SQL
? 5，使用行版本隔離級別
? 6，根據(jù)SQL建立索引
? 7，安裝SQL 2008 SP2補丁

? 8，禁止讀取大量數(shù)據(jù)未分頁的SQL，讀出數(shù)據(jù)必須分頁50條。

?

第二階段優(yōu)化
? 經(jīng)過一個多月的優(yōu)化，比以前穩(wěn)定一些，但系統(tǒng)100%的情況還有發(fā)生，這時分析下來，可能存在一些原因：
?? 1,高并發(fā)
?? 2,嚴重系統(tǒng)缺陷
?? 3,死鎖
?? 4,緩存問題
?? 5,循環(huán)調(diào)用SQL
?? 6,長事務(wù)
?? 7,未優(yōu)化的SQL
? 為跟蹤以上出現(xiàn)的SQL，發(fā)現(xiàn)以前用的DMVS性能分析視圖遠遠不夠，必須使用SQL Profile等其他工具，這期間的確進步很大
?? 1，使用SQL Profile監(jiān)控工具監(jiān)控高耗CPU的SQL
?? 2，發(fā)現(xiàn)長事務(wù)，并優(yōu)化程序和SQL缺陷
?? 3，發(fā)現(xiàn)SQL事務(wù)中的執(zhí)行語句停頓問題
?? 4，跟蹤引起死鎖SQL，并分析死鎖原因和優(yōu)化
?? 5，使用windows的性能工具分析CPU，Reads發(fā)現(xiàn)系統(tǒng)問題
?? 6，使用SSRS和windows的性能工具每天發(fā)送CPU跟蹤報表。
???

?第三階段優(yōu)化
??? 經(jīng)過一，二階段優(yōu)化，系統(tǒng)100%比以前的少了很多，但有一天，看SSRS的CPU報表，突然CPU暴漲到100%，而且第二天還有，通過Profile發(fā)現(xiàn)是因為緩存更新的原因，由于后臺修改數(shù)據(jù)會觸發(fā)緩存更新，一旦后臺大量更新數(shù)據(jù)時，前臺就會更新大量緩存，這樣一來就要很多個SQL請求，CPU就會暴漲到100%，后來修改了程序緩存策略，該問題解決。

? ? 經(jīng)過這三輪的優(yōu)化，系統(tǒng)的性能比以前有了明顯的改善，系統(tǒng)100%的情況極少。經(jīng)過這幾個月優(yōu)化，徹底發(fā)現(xiàn)以前的知識和經(jīng)驗不足，并一度懷疑自己的能力，為何以前優(yōu)化系統(tǒng)，1,2個月就大概全部搞定，這次花了這么長時間，可能情況不一樣，系統(tǒng)的復雜程度也不一樣吧！

? 2011年3月3日CPU的趨勢圖

?

? 2011年5月3日CPU的趨勢圖

?

??? 2011年7月7日CPU的趨勢圖

??

?

轉(zhuǎn)載于:https://www.cnblogs.com/zping/archive/2012/01/12/2320806.html

總結(jié)

以上是生活随笔為你收集整理的2011年2月--2011年7月数据库性能优化过程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。