30分鐘帶你熟練性能優化的那點兒事兒（案例說明）

前言

　　性能優化是數據庫運維人員和中、高級軟件開發人員的必備技能，不少時候老司機和新司機的區別就在寫出的東西是否優化。

　　博主接觸過近千家客戶的系統，這些系統都存在着各類各樣的性能問題。那麼如何透徹的瞭解咱們的數據庫性能問題？今天就用一個案例來講明性能優化的那點兒事兒。

　　PS:不少技術人員對優化有一套本身的理解，在閱讀本文前請放下你本身的理解。

　　正所謂：跟着博主不迷路，博主帶你上高速！

 　 點開案例跟着博主的思路看看優化這些事兒 ： 本文案例Demo

　　

 

瞭解系統環境

　　優化首先要知道數據庫在一個什麼樣的硬件/軟件環境下運行？配置是怎麼樣的？內存、CPU這些是否能徹底被應用？數據庫體量多大？

　　首先咱們先看一下系統的配置：

　　軟件層面，咱們要知道咱們的操做系統版本，SQL Server版本，以及對應版本的硬件限制（如32位系統不開AWE沒法使用超過4G內存、server 2008 標準版最大支持32G內存等）

 

　　本例中咱們能夠看出，系統環境沒有異常問題，SQL Server的補丁不是最新的，CPU資源不充足，可能CPU會成爲系統的瓶頸。

全局層面看性能

　　全局層面看問題主要指綜合服務器的各類指標表象定位系統的瓶頸或問題，在性能優化中最忌諱的就是看到一個指標立刻就下手，針對一個指標的判斷是盲目的，極可能使問題偏離自己的根本緣由，也可能使優化根本沒法解決根本問題而只是表象獲得了緩解。

　

性能計數器

　　CPU：在大量時間內CPU的使用率達到100%，說明CPU已經成爲瓶頸。

　　

　　內存：內存計數器生命週期在11點時已經降到0，惰性寫入器也彪高，說明內存也存在壓力，並且比較嚴重。

　　

　　磁盤：磁盤的平均隊列很高（通常系統最佳狀況隊列應該低於2），而且讀隊列和寫隊列都很高。因爲內存存在壓力，因此如今沒法判斷磁盤的壓力是因爲內存不足引發的仍是磁盤速度不能知足須要。

　　

 

 

 　　其餘計數器：

　　能夠看到系統中全表掃面的次數比較多，這代表不少查詢沒有應用索引。

　　

　　系統在11點左右和11點24左右發生大量鎖等待，而且等待時間很長（超過150s）

    

　　經過不少類計數器能綜合看出系統的問題。這裏不一一細說了

　　

　

系統等待

　　等待是另外一個能夠全局層面看系統的指標，系統運行的卡慢問題很大部分是由於等待而引發的，那麼等待的類型也是能夠很直觀的反映出系統的問題。

　　幾個主要等待：　　

　　ASNC_NETWORK_IO：通常反應出有部分查詢可能返回大量數據，請加查具體的等待語句是否須要返回如此多的數據。

　　WAITFOR ：多是配置了CDC發佈訂閱或程序中使用了語句waitfor delay

　　CXPACKET：CPU的調度等待。

　　LCK_M_U ：更新語句之間的語句阻塞。

　　WRITELOG：說明程序中有循環的插入跟新操做而頻繁的寫入日誌，磁盤速度不能知足寫入頻率而形成。

　　

 

　

綜合分析

　　綜合系統等待和性能計數器，咱們基本能夠斷定出來系統存在如下問題：

　　系統的CPU、內存、磁盤均存在較大的壓力，尤爲CPU負荷接近100%，系統中存在大量表掃面可能缺失比多索引。系統中有的語句可能要返回大量的沒必要要數據，系統鎖狀況嚴重，等待時間很長，語句執行時間也必然很長。

　　語句執行的總體狀況：因爲上述的問題影響，那麼系統中必然存在大量的長時間語句！

　　

 

解決問題

　　問題的定義是很重要的一步，從全局的多項指標綜合分析，讓全部問題無所遁形。定位問題後咱們先來看一下解決這些問題的基本步驟。

　　本案例是本身模擬的一個狀況，因此雖然在表象上來看資源壓力很大，但實際在運行的語句很少，場景也有限，但在生產系統若是存在這樣的表象，那麼說明你的系統性能問題很是嚴重急需一次詳細的優化了。

　　那麼下面也介紹一下生產系統遇到這樣的問題應該怎麼優化，有哪些必要的步驟。

步驟一 針對系統問題對數據庫進行全面的優化，提高總體效率

　　不少人優化可能直奔語句，認爲語句就能夠解決性能的全部問題，其實這樣的觀點是不全面的，系統的配置，數據庫的配置，索引的規劃等都是解決性能的必要步驟。

　　例如：系統中的語句都是最佳的，數據庫運行仍是很慢，可能就是由於你的CHECKDB配置的問題，也有可能由於你自動收縮沒有關閉而致使的性能問題。

 

優化操做系統配置

　　針對服務器進行配置檢查，查看是否有配置不合理或能夠優化的配置項，好比是否配置了虛擬內存？服務器層面是否限制的資源使用？服務器是否高性能模式運行？

 

優化數據庫層面的配置

　　針對數據庫參數進行合理配置使硬件充分發揮硬件功能，優化不合理配置，下降對數據庫形成衝擊的可能性。好比：最大並行度？最大內存？

　　

 

 

是否大量缺失索引

　　大量索引缺失必然致使語句性能不佳，而且消耗大量的系統資源，極可能就會形成上面服務器高壓力的表象

　　

 

刪除無用索引

　　針對數據庫中無用的索引進行刪除。提高更新操做的時間。

 

刪除重複索引

　　針對數據庫中重複的索引進行刪除。提高更新操做的時間。

　　

 

對重點語句建索引

　　針對系統中消耗大的語句或執行次數多的語句進行分析，評估語句性能問題，並創建合適的索引提，下降語句的資源消耗，升語句運行效率。

 

解決阻塞

　　解決語句間的阻塞，這須要分析語句的阻塞鏈，到底語句被什麼樣的操做阻塞了，爲何會阻塞？

　　不少新手常常問的問題：爲何我有的時候查很快有的時候查就很慢？ 答：大多數狀況就是你的語句被阻塞了。

　　

 

優化TempDB

　　針對TempDB調優，減小TempDB資源爭用致使的壓力。本例中能夠死看到有TempDB的爭用等待，因此對TempDB的優化也是必要的。

 

 

優化日誌碎片

　　針對日誌增大，帶來的日誌碎片問題進行優化。

清除索引碎片

　　檢查系統的索引維護狀況，並針對碎片過大的表進行碎片清除操做。主要體如今系統中有老化的索引，索引的老化致使索引的性能不高或失效。

 

一階段預期效果

 

　　一階段的優化是對性能的總體提高，性能提高也會很明顯，針對不一樣系統提高通常在2-3倍。

步驟二 處理熱點問題

　　處理熱點問題主要是在階段一的基本優化後針對重點的語句進行調優，可能包含建立索引，修改寫法，查詢提示，計劃嚮導等等。

　　在語句調優中請主要關注：是否有缺失索引，是否存在隱式轉換，語句的執行時間、CPU、邏輯讀寫量、物理讀寫量、佔用TempDB空間等信息。

 

　　例：這樣一條語句通過第一階段的優化並無太大的提高，並且資源消耗依然很大，那麼咱們能夠針對這條語句進行詳細的二階段優化。

　
　

簡單的優化一下

　　　

　　只是簡單的改了下語句的寫法時間有7秒變成1秒，內存消耗從300+MB 變成 1MB

 

 

二階段預期效果

    階段二的優化屬於細緻的優化步驟，要針對更爲具體的語句、具體的狀況。通過本階段優化可使系統中大部分語句從寫法、配置、運行指標都趨於優化值。

 

步驟三 針對業務

　　這個步驟須要配合開發人員，到底哪些功能依然慢？執行了哪些語句？是領導用的功能？仍是通常能夠慢的功能？若是大領導用的功能，那可能你就須要多花些心思了。這部分這裏就不展開說了。

 

三階段預期效果

    第三階段屬於最細緻的階段，能夠結合業務真正點對點的消滅系統中存在問題。

導圖

　　針對性能優化奉上幾個圖但願能幫助數據庫從業者梳理一下優化的思路（我的思路僅供參考，不完善的地方也請見諒）

　　

CPU：

　　

 

 

　　內存：

 　　

 

 

　　磁盤：

　　

 

 

　　等待：

　　

 總結

　　在性能優化中最忌諱的就是看到一個指標立刻就下手，針對一個指標的判斷是盲目的，極可能使問題偏離自己的根本緣由，也可能使優化根本沒法解決根本問題而只是表象獲得了緩解。

　　本文只是經過一個例子簡述一下優化的基本思路，但願幫助更多數據庫從業者，瞭解性能優化。

　　本文只闡述了思路，具體的各部分解決方式請參見個人系列文章：SQL SERVER全面優化-------Expert for SQL Server 診斷系列

　　性能的調優是一個持續性的工做，不是一次解決了問題之後就能夠高枕無憂了，按期的巡檢也是數據庫從業者必要的工做之一，作到及早發現及早解決。

　　巡檢系列文章請參見：輕鬆精通數據庫管理之道——運維巡檢系列

 

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

注：此文章爲原創，歡迎轉載，請在文章頁面明顯位置給出此文連接！
若您以爲這篇文章還不錯請點擊下右下角的推薦，很是感謝！