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

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

　奉上一幅草圖

　　系統(tǒng)壓力：訪問(wèn)壓力（也是我們常說(shuō)的并發(fā)）其實(shí)并不大，用戶連接數(shù)也沒(méi)想像的那么多

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

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

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

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

1. 　硬件資源確實(shí)有壓力
2. 　語(yǔ)句之前的阻塞太嚴(yán)重了，＂ＬＣＫ＿Ｍ＿＂，而且等待時(shí)間過(guò)長(zhǎng)，竟然平均達(dá)到幾百秒

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

　　下面我們來(lái)看看....

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

　　很多時(shí)候系統(tǒng)慢要究其原因，難道上線時(shí)候就這么慢？那不可能，廠商根本無(wú)法交付的！那么問(wèn)題來(lái)了，什么時(shí)候開(kāi)始慢的？對(duì)系統(tǒng)做過(guò)哪些調(diào)整？

　　簡(jiǎn)單的調(diào)研開(kāi)始...

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

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

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

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

　　預(yù)期：

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

　　結(jié)果：

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

　　優(yōu)化前

　　優(yōu)化后

　　優(yōu)化前

　　優(yōu)化后

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

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

1. 內(nèi)存某些時(shí)候還是存在波動(dòng)，但整體IO 內(nèi)存已經(jīng)不是瓶頸。
2. 系統(tǒng)中有SLEEPING的程序阻塞時(shí)間長(zhǎng)
3. 部分功能語(yǔ)句依然慢，消耗的資源很高。

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

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

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

　　一：報(bào)表

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

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

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

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

　　千萬(wàn)級(jí)別....

　　二：接口

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

　　三：?jiǎn)栴}代碼

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

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

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

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

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

　　針對(duì)第三部分業(yè)務(wù)語(yǔ)句進(jìn)行細(xì)致優(yōu)化，查詢提示，計(jì)劃向?qū)А⒅鼐幾g等等手段...

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

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

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

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

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

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

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

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

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

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

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

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

1. 　　OLAP和OLTP分離事務(wù)阻塞得到解決
2. 　　報(bào)表服務(wù)器和業(yè)務(wù)服務(wù)器可以根據(jù)自身的業(yè)務(wù)特別進(jìn)行單獨(dú)的個(gè)性化設(shè)置
3. 　　根據(jù)報(bào)表的要求我們配置高速I(mǎi)O的硬件

　　預(yù)期：

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

　　結(jié)果：

　　系統(tǒng)快起來(lái)了！

　　最終業(yè)務(wù)系統(tǒng)節(jié)點(diǎn)全天24小時(shí)的慢語(yǔ)句數(shù)量：（雖然還有慢語(yǔ)句存在，畢竟是TB級(jí)別的數(shù)據(jù)量，不影響業(yè)務(wù)運(yùn)行客戶完全可以接受！）

--------------博客地址---------------------------------------------------------------------------------------

Expert 診斷優(yōu)化系列 http://www.cnblogs.com/double-K/

-----------------------------------------------------------------------------------------------------

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

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

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

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

　　本文的優(yōu)化過(guò)程主要是：全面分析系統(tǒng)問(wèn)題——〉宏觀層面解決（環(huán)境、數(shù)據(jù)庫(kù)內(nèi)部運(yùn)行因素、硬件壓力）——〉低效代碼調(diào)整——〉架構(gòu)方案實(shí)現(xiàn)（穩(wěn)定、安全、高效）——〉最終系統(tǒng)順暢 無(wú)壓力

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

 ----------------------------------------------------------------------------------------------------

注：此文章為原創(chuàng)，歡迎轉(zhuǎn)載，請(qǐng)?jiān)谖恼马?yè)面明顯位置給出此文鏈接！
若您覺(jué)得這篇文章還不錯(cuò)請(qǐng)點(diǎn)擊下右下角的推薦，非常感謝！

如果您也遇到類(lèi)似問(wèn)題歡迎添加微信技術(shù)交流