寫在前面的故事
首先，給看官們講個故事：最近遇到過一個客戶，系統上線三年變的越來越慢，直到前幾個月全面爆發，系統前端使用人員不斷抱怨，甚至已經達到了不能使用的程度。這個時候他們的IT主管也是決策者無法忍受這種情況，就召集下面的運維開會，詢問情況。
上司：現在系統這麼慢，前端都無法使用了，到底什麼情況？
運維人員A：我們的伺服器CPU壓力太大，一直處于90%以上！
運維人員B：我們的伺服器記憶體不足總是90%以上！
運維人員C：我們的磁盤速度跟不上了，換SSD會有很大提高！
上司：啥都不行了？那我們換高配伺服器！
。。。。。。。。。。。。。。
換了伺服器，好了半個月又開始慢...和之前一樣基本沒有任何緩解...上司又召集運維人員開會。
上司：伺服器都換了，配置增加了一倍還多，為什麼還慢？
運維人員：我們需要做讀寫分離，做叢集分擔壓力！
運維人員：軟體不行了，這個軟體太差！
上司：。。。。
如果你是上司，那麼你該如果決策呢？ 如果你是運維人員，你會有上面的回答麼？
可能你看完會笑，認為這是不可能發生的故事，然而這個故事确實是真實的！反之如果這個故事中看到了自己,那麼請仔細地往下看喽！
--------------部落格位址---------------------------------------------------------------------------------------
Expert 診斷優化系列 http://www.cnblogs.com/double-K/
廢話不多說，直接開整-----------------------------------------------------------------------------------------
資料庫在系統中的角色
這個可能不用多說，大家都知道，一般系統慢都是慢在後端，而後端主要慢在與資料庫的互動！
資料庫可以了解成獨立于你的系統，成為一個單獨的系統。無論從資料庫的實體設計，與前端的互動方式，自身的參數設定，索引的設計，維護方案等都影響着你整個系統中最慢的環節（可以說整個系統中資料庫就是最慢的環節）！
同樣通過資料庫的狀态，也能很大程度上判定出你系統的問題到底在哪。尤其能界定清的一點就是軟體真的慢麼？軟體設計的不好？還是資料庫年久失修？
幾個問題
你了解你的資料庫麼
了解決定效率
也許很多老司機有這樣的感覺，我運維的效率如何，這取決于我對系統的了解！出現什麼樣的情況，我就知道是哪裡的問題，代碼在哪裡，問題在哪裡！看錯誤号、看異常便知問題，也就是未出茅廬，已知三分天下！反過來新手可能需要debug跟一遍還一知半解。對于資料庫道理也是一樣的，資料庫系統出現什麼問題你是否能很準确的定位的可能發生問題的幾個點？或者我需要檢視系統哪些名額？系統中存在着哪些隐患？哪些功能慢？哪些語句需要優化？哪些運維政策做的不合理？
出現問題能從容面對麼
從容出自積累
從容面對這個詞說起來容易,但是我自身從小白的開發到現在的DBA一路走來真的是積累了很多，坑也踩了很多才能做到從容面對。
這裡舉幾個現象 :
當你的CPU從穩定的30% 飙升到90%以上,你能想到的可能原因是什麼? 怎麼樣快速排查?
當你平穩的業務出現大面積逾時,你能想到的可能原因是什麼? 怎麼樣快速排查?
真的了解麼
習慣至深入
在很多次和運維人員交流的過程中發現，我知道的名詞和他知道的名詞完全不是一個東西！比如：死鎖。同樣提到索引，他會說不用講，這我都懂。那麼什麼是聯合索引，什麼是覆寫索引？覆寫索引怎麼能降低你的死鎖機率？ 這時他的反應才是：哦...原來還可以這樣，原來還有這麼多東西！
模拟一個場景，上司開會的時候問你如下問題：
上司問：
- 資料庫有多大 ？ 每天增長多少 ?
- 高峰時間卡慢麼 ? 為什麼慢 ? 資料庫問題還是軟體或硬體？
- 系統中那些語句慢 ? 慢到什麼程度？
- 系統中哪些資源是瓶頸 ?
- 存在死鎖情況麼？ 怎麼産生的？
- 有什麼潛在風險 ？
- 怎麼解決 ？
很多人運維人員的回答可能是：
。。。。。。。。。。
而問題發生的時候可能發生的情況就是這樣的：
你是哪一類？
背景：今天，資料庫普遍存在問題，如：性能問題、安全問題、可靠性問題、資料備份問題、結構設計問題等。
結論：
- 當出了問題時，使用者不知道是誰的原因，系統的真實狀況如何？
- 問題一大堆，多數人沒意識到是資料庫問題，很多人想弄但不會弄，還有一部分人會弄但傳統的方法不友善。
你是下面那個角色？
你是否像救火隊員？犧牲着自己的休息時間随叫随到的運維這你的系統？你是否像拆彈兵一樣維護着一個随時爆炸的系統？你是否又像一個保姆，寸步不離的呵護着你的系統？
怎麼辦？
可能不少看官就是上面的一員，但是又很迷惑，我該怎麼辦？我要從頭深入學習資料庫？學個幾年到精通？ 當然不需要，其實資料庫運維很簡單！你隻需要了解正常的運維套路，正常的系統名額，和正常的問題排查方式，這樣已經可以解決80%的問題。如果出現搞不定的20%你需要的資料庫專業人員的協作。
運維三步走:
- 發現問題
- 解決問題
- 預防問題
是不是感覺說的很輕巧...本文除了讓運維人員了解資料庫在系統中的重要，多關注資料庫，多了解一些資料庫的運維方式外，也推薦一款工具，所謂工欲善其事，必先利其器！
推薦一款工具
Expert for SQLServer 一款SQLSERVER的體檢診斷專家。
發現問題
全面體檢（不僅僅是性能），讓你知道資料庫的真實運作狀況、存在的問題及潛在風險
按照6大次元， 108項名額（軟硬體環境、參數配置、結構設計、性能、可用性、備份、安全）建立體檢标準，定期對資料庫進行全面體檢，客觀呈現資料庫的真實運作狀況，所有問題一覽無餘。
解決問題
快速診斷，分析出系統的主要問題并進行分類，同時提供解決之道
通過資料分析，将資料庫的問題按照嚴重程度進行分類，按照提示的方式進行調整，所有問題。不管你懂資料庫還是不懂資料庫，你都可以清晰地知道，應該從哪入手，進而快速地解決問題，讓天下沒有難用的資料庫。
預防問題
定期體檢，才能消滅隐患，買輛車還定期保養呢，這就是所謂的防患于未然，把問題消滅在萌芽中。
個人建議，不管你用什麼工具，或使用腳本。
核心系統體檢：1月/次
重要系統：2月或3月/次
有功能上線，或結構變更等都需要做一次體檢。
多人或大牛協作
就像一個系統運轉有硬體，網絡，程式，資料庫，需要多方、多人協作一樣，資料庫的問題一樣，每個人都有擅長的部分，那麼多人協作就是可以更全面的解決系統問題，這款工具的最大優勢在于提供了多人協作的基礎資料。這份體檢資料包含了資料庫運作中的大部分名額，所有時間點的狀況，計數器的名額，語句間的阻塞等等資訊，這遠勝于傳統運維中拼湊堆砌出來的腳本資料。
這就像醫院的電子病曆，對全身有了全面的檢查，X光片子、各種檢驗、化驗資料在手，可能你去到哪個醫院，找哪個專家或醫生彙診都可以作為他們協作的依據！
-----------------------------------------------------------------------------------------------------
總結 ： 親身處理了上百家客戶的系統，大部分系統資料庫都存在着各種資料庫問題，而資料庫問題往往被忽視，直接被歸結為軟體的問題，廠商的問題！
資料庫應該被我們重視起來，很多時候隻是在資料庫上做一些正常的配置或簡單的優化，就能讓系統有幾倍甚至幾十倍的提升，而這些優化可能隻是簡簡單單的資料庫層面完全不用改代碼的行為！
系統運維需要定期體檢，這點真心希望運維人員能夠重視起來，也真心希望系統運維人員可以加深一下對資料庫的了解，多掌握一些正常的手段和必要的運維政策。
工欲善其事，必先利其器，運維同樣需要一些簡單友善的工具！
本文提到的工具下載下傳連結：
Expert for SQLServer 工具下載下傳連結： http://zhuancloud.com/ReceptionViews/Install.html
本人使用工具優化的相關文章連結 ：
SQL SERVER全面優化-------Expert for SQL Server 診斷系列
----------------------------------------------------------------------------------------------------
注：此文章為原創，歡迎轉載，請在文章頁面明顯位置給出此文連結！
若您覺得這篇文章還不錯請點選下右下角的推薦，非常感謝！
引用高大俠的一句話 ：“拒絕SQL Server背鍋，從我做起!”