寫在前面的故事
首先，給看官們講個故事：最近遇到過一個客戶，系統上線三年變的越來越慢，直到前幾個月全面爆發，系統前端使用人員不斷抱怨，甚至已經達到了不能使用的程度。這個時候他們的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 診斷優化系列 http://www.cnblogs.com/double-K/
-----------------------------------------------------------------------------------------------------
總結 ： 親身處理了上百家客戶的系統，大部分系統數據庫都存在着各種數據庫問題，而數據庫問題往往被忽視，直接被歸結為軟件的問題，廠商的問題！
數據庫應該被我們重視起來，很多時候只是在數據庫上做一些常規的配置或簡單的優化，就能讓系統有幾倍甚至幾十倍的提升，而這些優化可能只是簡簡單單的數據庫層面完全不用改代碼的行為！
系統運維需要定期體檢，這點真心希望運維人員能夠重視起來，也真心希望系統運維人員可以加深一下對數據庫的了解，多掌握一些常規的手段和必要的運維策略。
工欲善其事，必先利其器，運維同樣需要一些簡單方便的工具！
本文提到的工具下載鏈接：
Expert for SQLServer 工具下載鏈接： http://zhuancloud.com/ReceptionViews/Install.html
本人使用工具優化的相關文章鏈接 ：
SQL SERVER全面優化-------Expert for SQL Server 診斷系列
----------------------------------------------------------------------------------------------------
注：此文章為原創，歡迎轉載，請在文章頁面明顯位置給出此文鏈接！
若您覺得這篇文章還不錯請點擊下右下角的推薦，非常感謝！
引用高大俠的一句話 ：“拒絕SQL Server背鍋，從我做起!”