記得在自己學習數據庫知識的時候特別喜歡看案例，因為優化的手段是容易掌握的，但是整體的優化思想是很難學會的。這也是為什么自己特別喜歡看案例，今天也分享自己做的優化案例。

之前分享過OA系統、HIS系統，今天我們來一個最常見的ERP。ERP系統各行各業都在用，不同行業也有不同的特點，博主在做研發的時候還自己寫過ERP也算是比較熟悉了。

不管是本文分享的零售類，還是鞋服門店、家居、汽車、地產等等，也不管是某友、某碟，ERP有一個共同的特點，單據流程長，業務復雜，熱點表明顯，數據量大，涉及眾多系統接口，各種大數據的統計報表....傳統行業又缺乏DBA精心管理。

慢是普遍的！

最近一直很忙，博客產出也少的可憐，今天整理了一下自己做過優化或各種方案的客戶已經超過千家，涉及各行各業，今天分享的案例算是在這些客戶中比較典型的了，沒有什么高大上都是常見的問題。在之前的博客中都有過提及，那么本篇我們就結合之前的技術點來看看這個案例。

用戶現象

系統慢！非常慢！

保存個單據要好幾分鐘，很多操作都超時，尤其到下午4點左右各種超時，收款什么的都收不了，查個報表一個小時，下班了還沒查完，經常因為系統慢而加班，業務部門怨聲載道。這個事情已經上報公司高層，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！

插入在刪除，中間還有跟業務表關聯操作，導致報表也會阻塞業務！

插入刪除的數據量是多少？ 你們猜一下？？

千萬級別....

二：接口

接口程序中頻繁調用業務數據并發更新頻繁，導致業務受阻。

三：問題代碼

代碼的問題主要有兩個：

代碼較復雜，需要細致優化。

程序中存在連接泄露，簡單理解成程序報錯后事務不能有效處理，導致事務未提交阻塞系統。

針對第一部分報表，語句更是復雜至極，這東西不是短期就可以優化的，考慮分出去；

針對第二部分接口，修改接口視圖，包括寫法優化、添加索引、調用頻率等；

針對第三部分業務語句進行細致優化，查詢提示，計劃向導、重編譯等等手段。

優化階段三（報表分離）

經過前兩個階段的優化一般系都會明顯好轉，只剩報表沒有處理，和一部分高消耗的頻繁接口查詢，這部分我們采用報表分離的方式去解決。

這里面我們遇到一個問題，報表要寫物理表。用2012 自帶的AlwaysOn是沒有辦法實現的（輔助節點只能讀）。

使用發布訂閱，又不能同時滿足數據安全和業務連續的要求，客戶又不滿意。

我們想到是否可以把寫入物理表變成寫入#temp 臨時表？ 軟件廠商給出的結論是：不可能....

那這里面我們使用了第三方的產品Moebius集群（這里真的不是廣告....）

如何實現：

多活集群，幾個節點數據實時一致，這樣的基本知識就不普及了...集群介紹也免了；

首先程序只有一個連接字符串沒法把報表指向到輔助服務器，我們只能通過Moebius集群的前端調度引擎，定制規則把報表所使用的存儲過程定點指向到第二臺服務器，解決了程序不能分離的問題。

其次Moebius集群可以實現兩個節點都可寫，以滿足輔助節點報表查詢寫入物理表的需要。

再次臨時表的寫入量太大，千萬級別數據同步也是問題，這里好就好在程序中寫入的物理臨時表都是以“Temp_” 開頭并以GUID類型結尾。我們在這里設置了只要這樣的表寫入不會反向同步給主節點，這樣根據規則控制雙向同步滿足了報表的要求，最終實現了報表的分離。

報表快了？ 當然沒有，只是分離不可能快，但是好處有三個：

OLAP和OLTP分離事務阻塞得到解決；

報表服務器和業務服務器可以根據自身的業務特別進行單獨的個性化設置；

根據報表的要求我們配置高速IO的硬件。

預期：

語句已經優化，阻塞情況也被解決，CPU、內存、磁盤壓力也沒有了，系統肯定快起來了！

結果：

系統快起來了！

最終業務系統節點全天24小時的慢語句數量：

（雖然還有慢語句存在，畢竟是TB級別的數據量，不影響業務運行客戶完全可以接受。）

總結

系統慢往往我們要全面分析，本文提供的維度：

業務壓力

硬件

環境

代碼

數據庫內部運行因素

架構

往往優化真的不是簡單的調一調語句，加一加硬件，全面地分析是根本解決性能問題的首要任務。

當然不是所有的優化都可以徹底解決，如本文中報表的改善是通過讀寫分離的方式實現，很多時候在ERP系統中報表的處理方式都是如此，報表如果細致優化，那需要多長時間呀！也許都是重寫了。

本文的優化過程主要是：

全面分析系統問題 → 宏觀層面解決（環境、數據庫內部運行因素、硬件壓力）→低效代碼調整→架構方案實現（穩定、安全、高效）→最終系統順暢無壓力。

當然此案例中客戶的數據量已經到了可以做數據分離、分區分表的階段，但分享本案例的原因也在于，不要認為上TB的數據一定就要分庫分表的各種拆分，在性能調優的簡單付出中依然可以收獲更大的收益，真心希望看官們在選擇分庫分表付出的極大代價之前可以找專業的人全面分析一下，仔細評估你的系統到底是什么瓶頸！