記得在自己學(xué)習(xí)數(shù)據(jù)庫知識(shí)的時(shí)候特別喜歡看案例，因?yàn)閮?yōu)化的手段是容易掌握的，但是整體的優(yōu)化思想是很難學(xué)會(huì)的。這也是為什么自己特別喜歡看案例，今天也分享自己做的優(yōu)化案例。

[[266374]]

之前分享過OA系統(tǒng)、HIS系統(tǒng)，今天我們來一個(gè)最常見的ERP。ERP系統(tǒng)各行各業(yè)都在用，不同行業(yè)也有不同的特點(diǎn)，博主在做研發(fā)的時(shí)候還自己寫過ERP也算是比較熟悉了。

不管是本文分享的零售類，還是鞋服門店、家居、汽車、地產(chǎn)等等，也不管是某友、某碟，ERP有一個(gè)共同的特點(diǎn)，單據(jù)流程長，業(yè)務(wù)復(fù)雜，熱點(diǎn)表明顯，數(shù)據(jù)量大，涉及眾多系統(tǒng)接口，各種大數(shù)據(jù)的統(tǒng)計(jì)報(bào)表....傳統(tǒng)行業(yè)又缺乏DBA精心管理。

慢是普遍的!

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

用戶現(xiàn)象

系統(tǒng)慢!非常慢!

保存?zhèn)€單據(jù)要好幾分鐘，很多操作都超時(shí)，尤其到下午4點(diǎn)左右各種超時(shí)，收款什么的都收不了，查個(gè)報(bào)表一個(gè)小時(shí)，下班了還沒查完，經(jīng)常因?yàn)橄到y(tǒng)慢而加班，業(yè)務(wù)部門怨聲載道。這個(gè)事情已經(jīng)上報(bào)公司高層，IT壓力非常大!

系統(tǒng)環(huán)境

首先我們來看一下這個(gè)系統(tǒng)配置及現(xiàn)狀，為什么說這個(gè)客戶經(jīng)典?往下看就知道了...

先來看看系統(tǒng)配置 ：

服務(wù)器的配置是：8路 24 core 做了超線程，384個(gè)邏輯CPU，內(nèi)存1T，磁盤全閃：

SQL用了2012版本，補(bǔ)丁已經(jīng)最新，而且服務(wù)器配置全部能夠識(shí)別。

沒錯(cuò)。相當(dāng)牛逼的配置!

數(shù)據(jù)庫的大小在1.2個(gè)T。

乍一看也許覺得是數(shù)據(jù)量太大了導(dǎo)致性能的問題，可又一想這么強(qiáng)力的服務(wù)器也不至于那么慢呀?難道是代碼的問題?難道需要分庫分表?

數(shù)據(jù)庫指標(biāo)

那么我們?cè)倏匆幌聰?shù)據(jù)庫的一些表象：

每秒請(qǐng)求數(shù)量：

用戶連接數(shù)：

語句執(zhí)行情況：

等待情況：

等待時(shí)間：

CPU指標(biāo)：

內(nèi)存一些指標(biāo)

磁盤隊(duì)列：

----------------還很多指標(biāo)就不一一展示了---------------

看到這些基本的指標(biāo)，除了慢你能看出什么?問題出在哪里?怎么樣快速解決?能有一個(gè)優(yōu)化的步驟呈現(xiàn)在眼前么?

分析

系統(tǒng)是真的很慢，慢語句數(shù)量很多系統(tǒng)阻塞也很嚴(yán)重，確實(shí)和客戶反映的慢可以吻合。那為什么這么慢?什么原因?qū)е碌?

我總結(jié)一般性能慢常和6大因素有關(guān)：

• 業(yè)務(wù)壓力
• 硬件
• 環(huán)境
• 代碼
• 數(shù)據(jù)庫內(nèi)部運(yùn)行因素
• 架構(gòu)

奉上一幅草圖：

系統(tǒng)壓力：訪問壓力(也是我們常說的并發(fā))其實(shí)并不大，用戶連接數(shù)也沒想像的那么多;

硬件：在內(nèi)存和磁盤IO確實(shí)存在壓力;

環(huán)境：服務(wù)器和數(shù)據(jù)庫版本什么的沒什么問題，具體配置一會(huì)兒再看;

代碼：最不想分析代碼，我們留到最后;

數(shù)據(jù)庫內(nèi)部運(yùn)行因素：從各種指標(biāo)來分析，系統(tǒng)語句等待時(shí)間太長，導(dǎo)致語句完成慢，而等待主要有兩部分：

• 硬件資源確實(shí)有壓力;
• 語句之前的阻塞太嚴(yán)重了，"LCK_M_"，而且等待時(shí)間過長，竟然平均達(dá)到幾百秒。

再分析...這么強(qiáng)的硬件，并不大的訪問壓力，竟然造成瓶頸?語句寫的爛?程序?qū)崿F(xiàn)的不好?缺索引?環(huán)境配置不對(duì)?

下面我們來看看....

優(yōu)化階段一(常規(guī)優(yōu)化)

很多時(shí)候系統(tǒng)慢要究其原因，難道上線時(shí)候就這么慢?那不可能，廠商根本無法交付的!那么問題來了，系統(tǒng)是什么時(shí)候開始慢的?對(duì)系統(tǒng)做過哪些調(diào)整?

簡單的調(diào)研，出擊!

我靠!!!廠商完全不配合，工程師對(duì)系統(tǒng)及其不熟悉，一問三不知，最近做什么改動(dòng)也說不清，用戶也不知道。廠商給的結(jié)論：繼續(xù)加硬件，更強(qiáng)的IO，數(shù)據(jù)分離減小數(shù)據(jù)量……

協(xié)調(diào)廠商完全協(xié)調(diào)不動(dòng)，基本沒戲了。

既然是數(shù)據(jù)庫問題，那我們就數(shù)據(jù)庫下手吧!從一名數(shù)據(jù)庫從業(yè)人員的角度來說，看到這樣的系統(tǒng)一定要先解決大面積等待問題。個(gè)人經(jīng)驗(yàn)來看很多系統(tǒng)大面積等待解決系統(tǒng)會(huì)有個(gè)很大的提升和改善。

配合一些常規(guī)的調(diào)優(yōu)手段，階段一開始了。主要給系統(tǒng)大面積創(chuàng)建影響高開銷大的索引，調(diào)整系統(tǒng)參數(shù)，優(yōu)化tempDB等....具體不細(xì)說了，前面系列文章中都有。

預(yù)期：

一般系統(tǒng)上面一輪優(yōu)化會(huì)有明顯的改善，我認(rèn)為這一輪以后系統(tǒng)會(huì)明顯變快，語句運(yùn)行環(huán)境合適，索引什么的合理資源消耗自然就少，內(nèi)存和IO壓力也會(huì)有所減少。

結(jié)果：

系統(tǒng)內(nèi)存，IO壓力趨于平穩(wěn)，慢語句數(shù)量有所減少，但依然很多，阻塞依然存在，超過2分鐘的語句依然很多。

優(yōu)化前：

優(yōu)化后

優(yōu)化前

優(yōu)化后

優(yōu)化階段二(針對(duì)語句)

再次分析解決大面積語句阻塞的系統(tǒng)，發(fā)現(xiàn)現(xiàn)在的情況，主要有如下幾個(gè)：

內(nèi)存某些時(shí)候還是存在波動(dòng)，但整體IO 內(nèi)存已經(jīng)不是瓶頸。

系統(tǒng)中有SLEEPING的程序阻塞時(shí)間長

部分功能語句依然慢，消耗的資源很高。

再次對(duì)系統(tǒng)調(diào)研：

• 執(zhí)行的慢語句是什么業(yè)務(wù)，是業(yè)務(wù)功能?還是報(bào)表?還是接口?
• 系統(tǒng)中頻繁且較慢的語句。
• 系統(tǒng)中阻塞的操作是什么。

調(diào)研后，我遇到了最常見也是最大的問題： 語句慢由于程序。在HIS的優(yōu)化案例中就是因?yàn)槌绦虼罅渴褂米远x函數(shù)，我們沒法改，我們巧妙的繞過。那么這次我們?nèi)绾卫@過?

一：報(bào)表

分析中發(fā)現(xiàn)程序系統(tǒng)中消耗最多資源的主要是報(bào)表。

報(bào)表通過一系列復(fù)雜的查詢插入到物理臨時(shí)表，啥叫物理臨時(shí)表? 就是非#temp 而是真真正正的插入到表中，用完在delete!

插入在刪除，中間還有跟業(yè)務(wù)表關(guān)聯(lián)操作，導(dǎo)致報(bào)表也會(huì)阻塞業(yè)務(wù)!

插入刪除的數(shù)據(jù)量是多少? 你們猜一下??

千萬級(jí)別....

二：接口

接口程序中頻繁調(diào)用業(yè)務(wù)數(shù)據(jù)并發(fā)更新頻繁，導(dǎo)致業(yè)務(wù)受阻。

三：問題代碼

代碼的問題主要有兩個(gè)：

代碼較復(fù)雜，需要細(xì)致優(yōu)化。

程序中存在連接泄露，簡單理解成程序報(bào)錯(cuò)后事務(wù)不能有效處理，導(dǎo)致事務(wù)未提交阻塞系統(tǒng)。

針對(duì)第一部分報(bào)表，語句更是復(fù)雜至極，這東西不是短期就可以優(yōu)化的，考慮分出去;

針對(duì)第二部分接口，修改接口視圖，包括寫法優(yōu)化、添加索引、調(diào)用頻率等;

針對(duì)第三部分業(yè)務(wù)語句進(jìn)行細(xì)致優(yōu)化，查詢提示，計(jì)劃向?qū)?、重編譯等等手段。

優(yōu)化階段三(報(bào)表分離)

經(jīng)過前兩個(gè)階段的優(yōu)化一般系都會(huì)明顯好轉(zhuǎn)，只剩報(bào)表沒有處理，和一部分高消耗的頻繁接口查詢，這部分我們采用報(bào)表分離的方式去解決。

這里面我們遇到一個(gè)問題，報(bào)表要寫物理表。用2012 自帶的AlwaysOn是沒有辦法實(shí)現(xiàn)的(輔助節(jié)點(diǎn)只能讀)。

使用發(fā)布訂閱，又不能同時(shí)滿足數(shù)據(jù)安全和業(yè)務(wù)連續(xù)的要求，客戶又不滿意。

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

那這里面我們使用了第三方的產(chǎn)品Moebius集群(這里真的不是廣告....)

如何實(shí)現(xiàn)：

多活集群，幾個(gè)節(jié)點(diǎn)數(shù)據(jù)實(shí)時(shí)一致，這樣的基本知識(shí)就不普及了...集群介紹也免了;

首先程序只有一個(gè)連接字符串沒法把報(bào)表指向到輔助服務(wù)器，我們只能通過Moebius集群的前端調(diào)度引擎，定制規(guī)則把報(bào)表所使用的存儲(chǔ)過程定點(diǎn)指向到第二臺(tái)服務(wù)器，解決了程序不能分離的問題。

其次Moebius集群可以實(shí)現(xiàn)兩個(gè)節(jié)點(diǎn)都可寫，以滿足輔助節(jié)點(diǎn)報(bào)表查詢寫入物理表的需要。

再次臨時(shí)表的寫入量太大，千萬級(jí)別數(shù)據(jù)同步也是問題，這里好就好在程序中寫入的物理臨時(shí)表都是以“Temp_” 開頭并以GUID類型結(jié)尾。我們?cè)谶@里設(shè)置了只要這樣的表寫入不會(huì)反向同步給主節(jié)點(diǎn)，這樣根據(jù)規(guī)則控制雙向同步滿足了報(bào)表的要求，最終實(shí)現(xiàn)了報(bào)表的分離。

報(bào)表快了? 當(dāng)然沒有，只是分離不可能快，但是好處有三個(gè)：

OLAP和OLTP分離事務(wù)阻塞得到解決;

報(bào)表服務(wù)器和業(yè)務(wù)服務(wù)器可以根據(jù)自身的業(yè)務(wù)特別進(jìn)行單獨(dú)的個(gè)性化設(shè)置;

根據(jù)報(bào)表的要求我們配置高速IO的硬件。

預(yù)期：

語句已經(jīng)優(yōu)化，阻塞情況也被解決，CPU、內(nèi)存、磁盤壓力也沒有了，系統(tǒng)肯定快起來了!

結(jié)果：

系統(tǒng)快起來了!

最終業(yè)務(wù)系統(tǒng)節(jié)點(diǎn)全天24小時(shí)的慢語句數(shù)量：

(雖然還有慢語句存在，畢竟是TB級(jí)別的數(shù)據(jù)量，不影響業(yè)務(wù)運(yùn)行客戶完全可以接受。)

總結(jié)

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

• 業(yè)務(wù)壓力
• 硬件
• 環(huán)境
• 代碼
• 數(shù)據(jù)庫內(nèi)部運(yùn)行因素
• 架構(gòu)

往往優(yōu)化真的不是簡單的調(diào)一調(diào)語句，加一加硬件，全面地分析是根本解決性能問題的首要任務(wù)。

當(dāng)然不是所有的優(yōu)化都可以徹底解決，如本文中報(bào)表的改善是通過讀寫分離的方式實(shí)現(xiàn)，很多時(shí)候在ERP系統(tǒng)中報(bào)表的處理方式都是如此，報(bào)表如果細(xì)致優(yōu)化，那需要多長時(shí)間呀!也許都是重寫了。

本文的優(yōu)化過程主要是：

全面分析系統(tǒng)問題 → 宏觀層面解決(環(huán)境、數(shù)據(jù)庫內(nèi)部運(yùn)行因素、硬件壓力) → 低效代碼調(diào)整 → 架構(gòu)方案實(shí)現(xiàn)(穩(wěn)定、安全、高效) → 最終系統(tǒng)順暢無壓力。

當(dāng)然此案例中客戶的數(shù)據(jù)量已經(jīng)到了可以做數(shù)據(jù)分離、分區(qū)分表的階段，但分享本案例的原因也在于，不要認(rèn)為上TB的數(shù)據(jù)一定就要分庫分表的各種拆分，在性能調(diào)優(yōu)的簡單付出中依然可以收獲更大的收益，真心希望看官們?cè)谶x擇分庫分表付出的極大代價(jià)之前可以找專業(yè)的人全面分析一下，仔細(xì)評(píng)估你的系統(tǒng)到底是什么瓶頸!