1. 程式人生 > >正確評估SQL資料庫效能,你必須知道的原理和方法!

正確評估SQL資料庫效能,你必須知道的原理和方法!

作者簡介: Max Shen(阿特),為了成為資料專家而努力,萬一實現了呢!

昨天寫了一篇如何監視資料庫效能,瞭解資料庫的執行狀態。被有人質疑,說沒有用。說要直接用資料庫的profile和monitor就可以了,到這一步那已經是到了資料庫查詢效能,已經到了調優的後期。對此我表示不認同,於是現在來寫一個評估資料庫的前言,談談資料庫效能問題所需要了解的內容。

基本概念

效能問題

什麼是效能問題?當系統出現效能問題,那麼反過來問為什麼說出現了效能問題,或者說到底怎麼樣算效能問題呢?

  • CPU100%,CPU佔有率過高?CPU就算是100%,但是客戶端反饋超快,算不算效能問題呢?
  • 剩餘記憶體過低?作業系統剩餘記憶體過低有可能是SQL吃完了,所以不一定。那如何知道SQL使用的記憶體情況呢?
  • 查詢慢?查詢慢,是否就是效能問題?如果一段儲存過程寫了500行,裡面關聯幾十個表,有複雜的邏輯運算,執行一次超過3000ms,這是慢還是快呢?所以所謂的查詢慢,也要有評估機制。
  • 查詢連結超時?查詢超時,連結超時就更復雜了,有n多因素影響。
  • …………

還有很多情況,客戶都說效能問題。所以到底什麼算效能問題呢?我個人認為是:

分為2種情況,第一是新系統執行與經驗系統相差巨大,效能測試和壓力測試不符合預期。第二種是正常執行系統發生與通常情況反映不一致狀態,導致業務執行困難。

通常效能下降是我們說的效能問題,但是:

還有效能突然提升,比如平常開啟頁面3秒鐘,突然什麼都沒有做變成了0.5秒。算不算效能問題呢?我認為也算效能問題,世界上絕對沒有無緣無故的愛,也沒有無緣無故的恨。所以突然的提升一定隱藏著更為重要的問題!

那麼既然有了概念,有哪些關鍵指標來評估資料效能問題呢?有了指標,我們就需要收集指標,所以有昨天的文章。

衡量效能問題的關鍵指標

響應時間(Response Time)

響應時間一般指的是一條SQL 語句執行後得出結果耗費的時間。
而一般使用者使用來說,比如BS結構,響應時間大家一般會認為是訪問頁面到頁面呈現結束,這樣的感官時間。這個時間就需要考慮更多的因素。比如網路、瀏覽器等等。曾經我碰到的CASE 頁面開啟速度超慢,但是資料庫正常,後來分析發現是頁面中潛入的一個很小的GIF影響了。所以要系統來分析。
而執行SQL語句獲得的響應時間是最為純粹的反饋,也是能夠得到準備資訊的步驟。
在系統跟蹤的話,可以用SQL profile 來跟蹤響應的內容,分析語句的反饋時間,之後再來詳細講解。

吞吐量(Thougput)

吞吐量是反映系統到底有多繁忙的指標,瞭解此指標可以更為清晰的知曉系統的使用狀況。
效能監視器中可以用SQL Batch Request/Sec,SQL Transactions /Sec等指標來獲取。

基線 (BaseLine)

BaseLine一直是我強調的指標。
基線是反映系統日常狀況的指標,如果知曉了系統的各種基線值。那麼就清楚了底在哪裡,天在哪裡。這樣才能更容易去判斷和解決問題。 而基線值是靠長期經驗和資料獲取的。

瓶頸(bottleneck)

系統一旦產生了瓶頸,我們就要去判斷瓶頸,而瓶頸一般來說多會有關聯性。比如記憶體不足可能導致IO過高,IO過高也可能導致CPU等待。
所以準確的知道瓶頸在哪裡,這是需要去判斷的。使用效能監視器和分析功能可以快捷的幫助大家分析瓶頸。

調優本質

調優的本質來講,一般的調優都指的是效能出現過高,需要系統穩定的情況。所以本質來講是幹以下事情:

降低工作負載

  • 減少查詢請求的數量:去除不必要的資料庫訪問
  • 降低查詢請求的複雜度:優化查詢邏輯的設計
  • 減少查詢請求之間的依賴關係:優化事務的設計和併發性控制

優化系統資源的配置

  • 找出系統資源瓶頸,增加相應的資源
  • 優化系統資源的分配

效能優化的方法學

如下圖,效能優化涉及的層面有:

  • 構架設計
  • 查詢優化
  • 索引優化
  • 併發控制
  • 儲存優化
  • 伺服器優化
    相關優化的成效和收益還要順序,可見下圖:

這裡寫圖片描述

優化的平衡

  • 優化是一個持續的過程,永無止境,解決了當前“最大”的瓶頸後,下一個“最大”的瓶頸又會出現
    要知道何時停止優化
  • 優化的內容應該是基於業務需求的優化
  • 關注二投資回報率(ROI) ,工程師的時間也是投入,因此要懂得投資回報,需要懂得停止優化!
  • 改變選項是最有意義的優化策略,有的優化是業務決定,那麼無法改變的時候是否可以改變業務邏輯。
  • 實際上,足夠好的效能就足夠了。很多時候足夠即可,而不是去尋找極限!

調優思路

調優思路來說,從理論上,在資料庫構架時候就應該介入。但是通常我們遇到的情況都是半路出來。發生問題才找到DBA。所以遵循的思路可以是如下:

這裡寫圖片描述

理解瓶頸,知道發生了什麼,然後做優化配置,調整執行慢的語句。
然後再反覆,反覆。

總結

調優是個系統工程,要有敏銳的觸覺,有可能一條引數改變整個系統感受。所以深入理解原理和方法,才能得心應手。 具體的方法,工具等敬請期待新的Blog。