寫在前面
記得在本身學習數據庫知識的時候特別喜歡看案例，由於優化的手段是容易掌握的，可是總體的優化思想是很難學會的。這也是爲何本身特別喜歡看案例，今天也分享本身作的優化案例。html
以前分享過OA系統、HIS系統，今天咱們來一個最多見的ERP，ERP系統各行各業都在用，不一樣行業也有不一樣的特色，博主在作研發的時候還本身寫過ERP也算是比較熟悉了。前端
無論是本文分享的零售類，仍是鞋服門店、家居、汽車、地產等等，也無論是某友、某碟，ERP有一個共同的特色，單據流程長，業務複雜，熱點代表顯，數據量大，涉及衆多系統接口，各類大數據的統計報表....傳統行業又缺少DBA精心管理。數據庫
慢是廣泛的！安全
SQL SERVER全面優化-------Expert for SQL Server 診斷系列
--------------博客地址---------------------------------------------------------------------------------------服務器
Expert 診斷優化系列 http://www.cnblogs.com/double-K/架構
廢話很少說，直接開整-----------------------------------------------------------------------------------------併發
用戶現象
系統慢！保存個單據要好幾分鐘，不少操做都超時，尤爲到下午4點左右各類超時，收款什麼的都收不了，函數
查個報表一個小時，下班了還沒查完，常常由於系統慢而加班，post
業務部門已經怨聲載道，這個事情已經上報公司高層IT部分壓力很是大！性能
系統環境
首先咱們來看一下這個系統配置及現狀，爲何說這個客戶經典？往下看就知道了...
先來看看系統配置 ：
服務器的配置是：8路 24 core 作了超線程 384個邏輯CPU，內存1T，磁盤全閃
SQL用了2012版本，補丁已經最新，並且服務器配置所有可以識別
沒錯。至關牛逼得配置！
數據庫的大小在1.2個T
咋一看也許數據量太大了，致使性能的問題！可又一想這麼強力的服務器也不至於那麼慢呀，難道是代碼的問題？難道須要分庫分表？
數據庫指標
那麼咱們再看一下數據庫的一些表象：
每秒請求數量：
用戶鏈接數：
語句執行狀況：
等待狀況：
等待時間：
CPU指標：
內存一些指標：
磁盤隊列：
-------------------還不少指標就不一一展現了------------------
看到這些基本的指標，除了慢你能看出什麼？問題出在哪裏？怎麼樣快速解決？能有一個優化的步驟呈如今眼前麼？
分析
系統是真的很慢，慢語句數量不少系統阻塞也很嚴重，確實和客戶反映的慢能夠吻合。那爲何這麼慢？什麼緣由致使的？
我總結通常性能慢常和6大因素有關：
- 業務壓力
- 硬件
- 環境
- 代碼
- 數據庫內部運行因素
- 架構
奉上一幅草圖
系統壓力：訪問壓力（也是咱們常說的併發）其實並不大，用戶鏈接數也沒想像的那麼多
硬件：在內存和磁盤IO確實存在壓力
環境 ：服務器和數據庫版本什麼的沒什麼問題，具體配置一下子再看。
代碼 ：最不想分析代碼，咱們留到最後
數據庫內部運行因素：從各類指標來分析，系統語句等待時間太長，致使語句完成慢，而等待主要有兩部分：
- 硬件資源確實有壓力
- 語句以前的阻塞太嚴重了，＂ＬＣＫ＿Ｍ＿＂，並且等待時間過長，居然平均達到幾百秒
再分析...這麼強的硬件，並不大的訪問壓力，居然形成瓶頸？語句寫的爛？程序實現的很差？缺索引？環境配置不對？
下面咱們來看看....
優化階段一（常規優化）
不少時候系統慢要究其緣由，難道上線時候就這麼慢？那不可能，廠商根本沒法交付的！那麼問題來了，何時開始慢的？對系統作過哪些調整？
簡單的調研開始...
我靠！！！廠商徹底不配合，工程師對系統及其不熟悉，一問三不知，最近作什麼改動也說不清，用戶也不知道。廠商給的結論：繼續加硬件....更強的IO....數據分離減少數據量！
協調廠商徹底協調不動，基本沒戲了！
既然是數據庫問題，那咱們就數據庫下手吧！從一名數據庫從業人員來講，看到這樣的系統必定要先解決大面積等待問題！我的經驗來看不少系統大面積等待解決系統會有個很大的提高和改善！
配合一些常規的調優手段階段一開始了,主要給系統大面積建立影響高開銷大的索引，調整系統參數，優化tempDB等....具體不細說了，前面系列文章中都有！
預期：
通常系統上面一輪優化會有明顯的改善，我認爲這一輪之後系統會明顯變快，語句運行環境合適，索引什麼的合理資源消耗天然就少，內存和IO壓力也會有所減小。
結果：
系統內存，IO壓力趨於平穩，慢語句數量有所減小，但依然不少，阻塞依然存在，超過2分鐘的語句依然不少。
優化前
優化後
優化前
優化後
優化階段二（針對語句）
再次分析解決大面積語句阻塞的系統，發現如今的狀況，主要有以下幾個：
- 內存某些時候仍是存在波動，但總體IO 內存已經不是瓶頸。
- 系統中有SLEEPING的程序阻塞時間長
- 部分功能語句依然慢，消耗的資源很高。
再次對系統調研：
- 執行的慢語句是什麼業務，是業務功能？仍是報表？仍是接口？
- 系統中頻繁且較慢的語句。
- 系統中阻塞的操做是什麼。
調研後，我遇到了最多見也是最大的問題： 語句慢因爲程序！在HIS的優化案例中就是由於程序大量使用自定義函數，咱們無法改，咱們巧妙的繞過。那麼此次咱們如何繞過？
一：報表
分析中發現程序系統中消耗最多資源的主要是報表。
報表經過一系列複雜的查詢插入到物理臨時表，啥叫物理臨時表？ 就是非#temp 而是真真正正的插入到表中，用完在delete！
插入在刪除，中間還有跟業務表關聯操做，致使報表也會阻塞業務！
插入刪除的數據量是多少？ 大家猜一下？？
千萬級別....
二：接口
接口程序中頻繁調用業務數據併發更新頻繁....致使業務受阻...
三：問題代碼
代碼的問題主要有兩個：
1.代碼較複雜，須要細緻優化。
2.程序中存在鏈接泄露，簡單理解成程序報錯後事務不能有效處理，致使事務未提交阻塞系統
針對第一部分報表，語句更是複雜至極...這東西不是短時間就能夠優化的，考慮分出去
針對第二部分接口，修改接口視圖，包括寫法優化、添加索引、調用頻率等；
針對第三部分業務語句進行細緻優化，查詢提示，計劃嚮導、重編譯等等手段...
優化階段三（報表分離）
通過前兩個階段的優化通常系都會明顯好轉，只剩報表沒有處理，和一部分高消耗的頻繁接口查詢，這部分咱們採用報表分離的方式去解決。
這裏面咱們遇到一個問題，報表要寫物理表！用2012 自帶的AlwaysOn是沒有辦法實現的（輔助節點只能讀）
使用發佈訂閱，又不能同時知足數據安全和業務連續的要求，客戶又不滿意。
咱們想到是否能夠把寫入物理表變成寫入#temp 臨時表？ 軟件廠商給出的結論是：不可能....
那這裏面咱們使用了第三方的產品Moebius集羣（這裏真的不是廣告....）
如何實現：
多活集羣，幾個節點數據實時一致，這樣的基本知識就不普及了...集羣介紹也免了
首先程序只有一個鏈接字符串無法把報表指向到輔助服務器，咱們只能經過Moebius集羣的前端調度引擎，定製規則把報表所使用的存儲過程定點指向到第二臺服務器，解決了程序不能分離的問題。
其次Moebius集羣能夠實現兩個節點均可寫，以知足輔助節點報表查詢寫入物理表的須要。
再次臨時表的寫入量太大，千萬級別數據同步也是問題，這裏好就好在程序中寫入的物理臨時表都是以「Temp_」 開頭並以GUID類型結尾。咱們在這裏設置了只要這樣的表寫入不會反向同步給主節點，這樣根據規則控制雙向同步知足了報表的要求，最終實現了報表的分離。
報表快了？ 固然沒有，只是分離不可能快，可是好處有兩個：
- OLAP和OLTP分離事務阻塞獲得解決
- 報表服務器和業務服務器能夠根據自身的業務特別進行單獨的個性化設置
- 根據報表的要求咱們配置高速IO的硬件
預期：
語句已經優化，阻塞狀況也被解決，CPU、內存、磁盤壓力也沒有了，系統確定快起來了！
結果：
系統快起來了！
最終業務系統節點全天24小時的慢語句數量：（雖然還有慢語句存在，畢竟是TB級別的數據量，不影響業務運行客戶徹底能夠接受！）
--------------博客地址---------------------------------------------------------------------------------------
Expert 診斷優化系列 http://www.cnblogs.com/double-K/
-----------------------------------------------------------------------------------------------------
總結 ： 系統慢每每咱們要全面分析，本文提供的維度：
- 業務壓力
- 硬件
- 環境
- 代碼
- 數據庫內部運行因素
- 架構
每每優化真的不是簡單的調一調語句，加一加硬件，全面地分析是根本解決性能問題的首要任務。
固然不是全部的優化均可以完全解決，如本文中報表的改善是經過讀寫分離的方式實現，不少時候在ERP系統中報表的處理方式都是如此，報表若是細緻優化，那須要多長時間呀！也許都是重寫了。
本文的優化過程主要是：全面分析系統問題——〉宏觀層面解決（環境、數據庫內部運行因素、硬件壓力）——〉低效代碼調整——〉架構方案實現（穩定、安全、高效）——〉最終系統順暢 無壓力
固然此案例中客戶的數據量已經到了能夠作數據分離，分區分表的階段，但分享本案例的緣由也在於，不要認爲上TB的數據必定就要分庫分表的各類拆分，在性能調優的簡單付出中依然能夠收穫更大的收益，真心但願看官們在選擇分庫分表付出的極大代價以前能夠找專業的人全面分析一下，仔細評估你的系統究竟是什麼瓶頸！
摘自：https://www.cnblogs.com/double-K/p/9210982.html