開始暴露問題
2023年2月下旬的一天早上，昨天更新的系統，早上發現資料庫的伺服器cpu達到100%，而且持續的時間很長，不得回到昨天更新前的版本，但系統還是有較長時間達到100%的情況，問題沒有解決，從這正式開始優化線上資料庫效能。
第一階段優化
分析問題：
一開始老是想找出問題的原因，找了3天還沒有頭緒，列出以下原因：
1，job的耗時儲存過程 --太頻繁，執行時間長，1,2分鐘
2，頻繁執行同樣的sql --如查詢使用者表sys_user 幾分鐘內執行數千次
3，tempdb太小
4，執行sql太慢
5，資料庫阻塞
但這些原因，都找不出具體的在那塊有問題，好像都有，又好像都沒有，時間在一天天過去，但是系統還是100%經常發生，嚴重影響業務使用，這時只能按照以前的優化經驗調整優化思路，不找原因，只要是問題就優化，乙個乙個處理，最終解決系統效能問題：
主要是執行優化方法：
1，刪除全部的主鍵聚集索引，改成唯一非聚集索引
2，刪除重建全部索引
3，刪除全部外來鍵約束
4，持續優化sql
5，使用行版本隔離級別
6，根據sql建立索引
7，安裝sql 2008 sp2補丁
8，禁止讀取大量資料未分頁的sql，讀出資料必須分頁50條。
第二階段優化
經過乙個多月的優化，比以前穩定一些，但系統100%的情況還有發生，這時分析下來，可能存在一些原因：
1,高併發
2,嚴重系統缺陷
3,死鎖
4,快取問題
5,迴圈呼叫sql
6,長事務
7,未優化的sql
為跟蹤以上出現的sql，發現以前用的dmvs效能分析檢視遠遠不夠，必須使用sql profile等其他工具，這期間的確進步很大
1，使用sql profile監控工具監控高耗cpu的sql
2，發現長事務，並優化程式和sql缺陷
3，發現sql事務中的執行語句停頓問題
4，跟蹤引起死鎖sql，並分析死鎖原因和優化
5，使用windows的效能工具分析cpu，reads發現系統問題
6，使用ssrs和windows的效能工具每天傳送cpu跟蹤報表。
第三階段優化
經過一，二階段優化，系統100%比以前的少了很多，但有一天，看ssrs的cpu報表，突然cpu暴漲到100%，而且第二天還有，通過profile發現是因為快取更新的原因，由於後台修改資料會觸發快取更新，一旦後台大量更新資料時，前台就會更新大量快取，這樣一來就要很多個sql請求，cpu就會暴漲到100%，後來修改了程式快取策略，該問題解決。
經過這三輪的優化，系統的效能比以前有了明顯的改善，系統100%的情況極少。經過這幾個月優化，徹底發現以前的知識和經驗不足，並一度懷疑自己的能力，為何以前優化系統，1,2個月就大概全部搞定，這次花了這麼長時間，可能情況不一樣，系統的複雜程度也不一樣吧！
2023年3月3日cpu的趨勢圖
2023年5月3日cpu的趨勢圖
2023年7月7日cpu的趨勢圖
寫在2023年1月
沒等家裡給安排研究所或國企，多少是害怕流言蜚語，讀了那麼多年書，還不是要家裡給安排工作 而且我很了解自己的性格，國企那樣的環境必不適合我，我討厭官僚的地方，也是擔心怕是我再努力也無法得到晉公升的機會。至於bj的問題，大概是6年前的一心嚮往吧。可是當我冷靜下來想的時候，如果只因為想去那邊每月多掙那幾千...
2023年8月 學習總結
八月是學校放暑假的時候，廣州的天氣不是一般的熱啊 這個暑假和中大的兩個博士一起高資料探勘的演算法開發，同時陪著acm的那些教主們訓練，打了一下醬油，今天是月末，就把這個月所做的東西好好總結一下吧。首先是acm演算法競賽方面，由於已經轉型成了乙個 兼職 的acmer，所以訓練強度和學習的範圍都下降了。...
2023年1月的週末
最近的主要工作是參與siebel專案實施,負責的是siebel與sap系統整合的這一塊兒.當然,sap的開發雖然已經有近兩年的經歷,但在系統整合 eai 這一塊兒,仍然只是個學徒工而已.專案開始之後就基本再沒週六,晚上偶爾加班半個鐘頭,這對我而言,已經是最忙的工作狀態了.忍不住道聽總結一下新年1月所...