好久沒寫博客了，一方面是日常工作繁忙，另外一方面是想更多的時間陪陪家里人，享受春天的美好時光，同時還在寫一本《程序員，你傷不起》的一本書要由人民郵電出版社出版；公司有2台超級強大的服務器，其中1台服務器是用來備份容災用的，防止老的服務器發生硬件故障時整個網站系統崩潰，若那樣會給公司帶來慘重的經濟損失；而且這樣超級強大的服務器不是今天訂貨明天就能送貨上門的。
大學剛畢業那會喜歡研究數據庫技術，那時候覺得數據處理很重要，而且數據庫優化更重要，看了很多數據庫性能優化方面的資料，平時設計軟件系統時也會多關心一下數據庫的性能問題。但是一直沒遇到專門做數據庫優化的DBA工作，就漸漸的放棄了數據庫專業發展道理。
不是每個公司都能有專業的數據庫DBA工作崗位，也未必請得起專業的高手DBA，就是請了人家也未必來對吧。因為沒那樣的好環境人的技能是容易走下坡路的當然也就更容易貶值而不是升值。
其實讓別人放心來弄公司的核心數據庫，放心讓你操作公司的核心主機，都需要有一個信任的過程；一方面是需要信任你的為人，另外一方面也能信任你的技能高超；因為有任何錯誤的操作可能會導致天大的錯誤，服務器停止運轉1個小時的直接經濟損失就是1-2萬元。而且還要在那么多客戶面前丟人現眼。間接的損失更是不可估量的會影響到網站的形象。
判斷數據庫的瓶頸需要一個過程，需要知道數據庫的瓶頸是出在哪里？ CPU？ 內存？ 網絡？ 磁盤？ 索引？sql語句？ 經過1周的分析優化（3個通宵），得出的結論是最核心的數據庫瓶頸問題出在磁盤的讀寫速度已經跟不上網站的數據大並發。
大學剛畢業那會兒也喜歡研究數據庫技術，但是當時迷茫，不知道數據庫技術能否派上用處，學了是否能找到個好職位、將來能重視到什么程度，其實多年在這方面的關注積累也奠定了1周時間能把服務器的性能提升4-5倍的可能。沒有積累是短時間內難突破的。當然也建議平時多看看這方面的書籍、網上的資料。
1：需要用性能監視器，來看看磁盤的性能，這個參數是建議小於2，在實際服務器上這個參數經常會跳到接近100，幾乎沒低於2個時候，而且是1天24小時都很大，這表明服務器的磁盤I/O已經遇到了瓶頸了。
2：磁盤隊列的長度經常是10-100，也比較大，感覺是有性能問題，而且服務器行的E,F盤只當備份用；24小時里，只有半個小時在發揮價值，C,D盤在瘋狂的大量數據讀寫，對磁盤的穩定性壽命都是一個極大的挑戰，好再服務器硬盤的質量好否則早就死翹翹了；由於主數據不能有任何閃失，也不能隨便轉移到其他硬盤上，主數據是做了RIAD5，所以把一些索引文件、臨時數據庫、日志文件都搬移到了E,F盤上，因為這些數據就是丟失了問題也不大，也沒必要恢復，這么修改了一下后，E,F盤也24小時不斷的利用上了，而且還減少了主盤的讀寫壓力。
下面的一張圖就是我們平時的台式機、這性能配置差距可不是一般的小，看看CPU數、內存數，就知道有多大差距了。這也是我目前以來親眼見過得最好的3個服務器之一，親自能管控的最好的2個服務器之一難得能感受駕馭這么強大的服務器快感。
3：把核心數據庫又分了幾個文件組、每個文件組又加了一些文件；把一些數據庫量超過百萬級別的表按業務邏輯進行了分區，同時做了一些索引優化等等工作。
4：把多個硬盤都合理利用，每個硬盤都按配置干不同的工作，經過進一步的優化，磁盤的隊列下降到10以內，偶爾高峰期會超過這個值，平時訪問量壓力不大時，磁盤隊列降低到了1以內，對主數據庫的磁盤壽命、磁盤的壓力都有了很大的改善。
經過這次的連續奮戰1周多，感覺自己在職業道路上又升華了一次，親自操刀優化了全球1000強的電子商務網站的核心數據庫，感覺到有些小驕傲。下次有機會再參加專業的數據庫優化的課程，再深入學習提高一下，也歡迎在杭州的數據庫維護管理人員朋友周末、晚上什么的一起喝茶聊天。
我的QQ：252056973
下次有空時，繼續把這次優化的經驗分享給大家。
