正確評價SQL數據庫功能,你有必要知道的原理和辦法!

昨日寫了一篇如何監督數據庫功能,了解數據庫的運轉狀況。被有人質疑,說沒有用。說要直接用數據庫的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。

相關新聞

聯系我們

400-080-6560

在線咨詢:點擊這里給我發消息

郵件:[email protected]

工作時間:周一至周日,09:00-18:30

QR code
云南快乐10分开奖直播