基本概念

性能問題

什么是性能問題？當系統出現性能問題，那么反過來問為什么說出現了性能問題，或者說到底怎么樣算性能問題呢？

• 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。