記得在自己學習數(shù)據庫知識的時候特別喜歡看案例，因為優(yōu)化的手段是容易掌握的，但是整體的優(yōu)化思想是很難學會的。這也是為什么自己特別喜歡看案例，今天也開始分享自己做的優(yōu)化案例。
最近一直很忙，博客產出也少的可憐，今天整理了一下自己做過優(yōu)化或各種方案的客戶已經超過100家了，今天分享的案例算是在這些客戶中比較典型的了！沒有什么高大上都是常見的問題！在之前的博客中都有過提及，那么本篇我們就結合之前的技術點來看看這個案例。學習優(yōu)化手段的看官們可以參見我的優(yōu)化系列：
系統(tǒng)環(huán)境
首先我們來看一下這個系統(tǒng)配置及現(xiàn)狀，為什么說這個客戶經典？那就是因為這個客戶已經達到可以慢的地方都慢，不該慢的地方也慢！
首先這是一套醫(yī)院的HIS系統(tǒng)，慢到什么程度呢？各種功能卡死不管是交款、醫(yī)囑、開藥一些列幾乎所有的功能都慢。但是卡慢的現(xiàn)象只出現(xiàn)在上午的高峰期！
先來看看系統(tǒng)配置 ：
?
?
?
?
?
數(shù)據庫版本是SQL SERVER 2008R2，數(shù)據量大概1個多T，服務器64CPU 、128G內存，服務器只運行數(shù)據庫。
咋一看服務器確實有點老了，數(shù)據量也大了，內存和CPU什么的明顯不夠用了！
數(shù)據庫指標
那么我們再看一下數(shù)據庫的一些表象：
每秒請求數(shù)量：
?
?
語句執(zhí)行情況：
?
?
等待情況：
?
?
等待時間：
?
?
? CPU指標：
?
?
內存一些指標：
?
?
磁盤隊列：
?
?
?-------------------還很多指標就不一一展示了------------------
? 看到這些基本的指標，除了慢你能看出什么？問題出在哪里？怎么樣快速解決？能有一個優(yōu)化的步驟呈現(xiàn)在眼前么？
優(yōu)化階段一（常規(guī)優(yōu)化）
很多時候系統(tǒng)慢要究其原因，難道上線時候就這么慢？那不可能，廠商根本無法交付的！那么問題來了，什么時候開始慢的？對系統(tǒng)做過哪些調整？
簡單的調研開始...給我的只有不到半天的調研時間...得知的基本問題就是系統(tǒng)在最近一月增加了很多功能，有上線了很多其他系統(tǒng)接口！
那么直接就搞新功能、新程序接口語句？ 我認為并不是這樣，從一名數(shù)據庫從業(yè)人員來說，看到這樣的系統(tǒng)一定要先解決大面積等待問題！個人經驗來看很多系統(tǒng)大面積等待解決系統(tǒng)會有個很大的提升和改善！
配合一些常規(guī)的調優(yōu)手段階段一開始了,主要給系統(tǒng)大面積創(chuàng)建影響高開銷大的索引，調整系統(tǒng)參數(shù)，優(yōu)化tempDB、開啟快照讀等....具體不細說了，前面系列文章中都有！
?
預期：
一般系統(tǒng)上面一輪優(yōu)化會有明顯的改善，我認為這一輪以后系統(tǒng)會明顯變快，語句CPU會下降到70%左右，內存壓力也會有所減少。
結果：
自信滿滿的我第二天去了各個科室....部分功能依然超時還是各種慢...CPU依然90%以上，內存壓力依然明顯。但是收集的數(shù)據來看，長時間語句數(shù)量已經大幅降低，系統(tǒng)等待阻塞情況也明顯好轉。
優(yōu)化前
?
?
優(yōu)化后
?
?
優(yōu)化前
?
?
優(yōu)化后
?
?
優(yōu)化階段二（針對語句）
? 再次分析解決大面積語句阻塞的系統(tǒng)，發(fā)現(xiàn)現(xiàn)在的情況，主要有如下幾個：
- 由于內存不足導致的IO壓力。
- 系統(tǒng)CPU依然彪高。
- 部分功能語句依然慢，消耗的資源很高。
再次對系統(tǒng)調研：
- 哪些功能慢，執(zhí)行的語句是什么。
- 系統(tǒng)的接口語句問題。
- 系統(tǒng)中還有哪些消耗資源高的語句，是否能優(yōu)化?！ ?/li>
調研后，我遇到了最常見也是最大的問題： 語句慢由于程序！很多人看到這會說程序慢就改唄，那有啥問題？ 問題就在于你來做優(yōu)化直接了當?shù)暮腿思议_發(fā)人員說你程序太爛必須改！如果你是程序開發(fā)人員你會有什么樣的反應？
他會說：對不起，影響太大改不了！
那么這個優(yōu)化項目黃了，或者你要付出更大的代價繞過這樣的問題。
?
?分析中發(fā)現(xiàn)程序使用了大量各種自定義函數(shù)，有一定經驗的人都應該知道，語句在篩選的列上使用函數(shù)是沒有辦法使用索引查找的，這樣相對于這種單表數(shù)據就幾百甚至幾千萬的表，是何等的災難！但是不能冒然突出修改程序，那還能怎么優(yōu)化呢？大概分析后得出結論，程序主要消耗在幾部分：
- 部分業(yè)務功能語句慢。
- 接口語句慢（主要是視圖，供其他程序調用）。
- 還有報表程序。
?
針對第一部分在不能改程序的情況下，嘗試添加計劃向導改變語句執(zhí)行情況；
針對第二部分修改接口視圖，包括替換掉函數(shù)、添加索引等；
針對第三部分報表這東西不是短期就可以優(yōu)化的，所以再原有鏡像的方案上添加快照，實現(xiàn)了簡單的讀寫分離，直接分走；
語句優(yōu)化的效果：
優(yōu)化前
?
?
優(yōu)化后
優(yōu)化前
?
?
優(yōu)化后
?
?
? 預期：
90%消耗高的語句都得到了優(yōu)化，系統(tǒng)應該可以快起來了，CPU、內存指標也應該正常了！
? 結果：
語句的消耗和時間都降下來了，系統(tǒng)卡慢現(xiàn)象有明顯好轉，但是CPU依然90%以上、內存壓力依然明顯，磁盤隊列還是很高！系統(tǒng)性能問題依然存在。
優(yōu)化階段三（深入指標分析）
經過前兩個階段的優(yōu)化一般系都會明顯好轉，并且指標正常，這也是前面提到的可以慢的地方慢已經解決，那么為什么CPU、內存壓力沒有緩解？難道真的是64CPU、128G內存不能支持了？需要加內存換CPU？難道要做負載均衡？各種拆分？
CPU分析
首先我對CPU壓力進行了分析，綜合語句的CPU消耗和CPU的表象來看，很大一部分應該不是語句執(zhí)行消耗的！那么服務器上確實也沒有跑其他程序，CPU資源哪里去了？
看看這個計數(shù)器：
?
?
SQL的編譯次數(shù)高峰時間段達到每秒2000多次！很多書上寫過，相信很多看官也知道，語句不參數(shù)化會給CPU造成壓力，這就是個鮮活的例子！那么解決辦法也是比較粗暴，程序無法修改那么就在數(shù)據庫上開啟強制參數(shù)化。
看下效果：
?
?
? 我想不用多說什么了！
內存分析
看到了CPU的現(xiàn)象那么內存的問題也有眉目了，這么多編譯即席查詢，首先看一下內存中緩存了那些數(shù)據：
?
?
SQLOPTIMIZER Singlepage占到了80多個G，而在查詢數(shù)據頁的緩存只有20個G，而且仍然在被不斷壓縮，那么內存沒壓力就怪了！這個SQLOPTIMIZER Singlepage嘗試了一下是無法通過DBCC FREExxxxx的操作釋放的，所以在半夜直接重啟了SQL 服務！將近2年沒有重啟的SQL服務就這么折在我的手里了！
? 重啟后頁生命周期：
內存這個問題，不知道是不是微軟的一個小BUG，查詢計劃的緩存?zhèn)€人理解不會一直壓榨數(shù)據緩存的，客戶的數(shù)據庫沒有補丁，但是查閱08的各個補丁也沒有找到相關問題的修復。
也請遇到過或了解的朋友給點提示！
?
預期：
語句已經優(yōu)化，阻塞情況也被解決，CPU、內存、磁盤壓力也沒有了，系統(tǒng)肯定快起來了！
結果：
系統(tǒng)快起來了！
?
總結 ： 文章只是簡單的描述了一下某醫(yī)院HIS系統(tǒng)的優(yōu)化過程，當然一周的工作僅僅通過一篇文章寫出全過程細節(jié)必然不那么詳盡，還望看官們見諒！
整個的優(yōu)化過程是程序只修改了2條語句，其他都是通過數(shù)據庫優(yōu)化手段完成。而且沒有添加任何硬件資源！文章來源：http://www.zghlxwxcb.cn/news/detail-450393.html
優(yōu)化過程主要分為：文章來源地址http://www.zghlxwxcb.cn/news/detail-450393.html
- 系統(tǒng)整體調研 ：和科室用戶溝通慢的情況，系統(tǒng)最近變更情況，并收集數(shù)據。
- 常規(guī)優(yōu)化 ： 調整數(shù)據庫參數(shù)配置，添加索引，解決阻塞。
- 再次調研：系統(tǒng)慢功能，慢語句。
- 針對語句優(yōu)化：寫法不足，是否缺失索引，是否能加提示、計劃向導等
- 整體壓力是否緩解：如果仍然壓力很大找到瓶頸，是否可以解決？如果不能解決才考慮添加硬件或選用分離、分離等方案。
到了這里，關于數(shù)據庫優(yōu)化案例—某市中心醫(yī)院HIS系統(tǒng)的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！
