總結
本章給出了一些基本的思路和技術有肋於你成功地進行性能優化正確的思維方式是開啟系統的全部潛力和應用本書其他章節提供的知識的關鍵下面是我們試圖演示的一些基本知識點
我們認為定義性能最有效的方法是響應時間
如果無法測量就無法有效地優化所以性能優化工作需要基於高質量全方位及完整的響應時間測量
測量的最佳開始點是應用程序而不是數據庫即使問題出在底層的數據庫借助良好的測量也可以很容易地發現問題
大多數系統無法完整地測量測量有時候也會有錯誤的結果但也可以想辦法繞過一些限制並得到好的結果（但是要能意識到所使用的方法的缺陷和不確定性在哪裡）
完整的測量會產生大量需要分析的數據所以需要用到剖析器這是最佳的工具可以幫助將重要的問題冒泡到前面這樣就可以決定從哪裡開始分析會比較好
剖析報告是一種匯總信息掩蓋和丟棄了太多細節而且它不會告訴你缺少了什麼所以完全依賴剖析報告也是不明智的
有兩種消耗時間的操作工作或者等待大多數剖析器只能測量因為工作而消耗的時間所以等待分析有時候是很有用的補充尤其是當CPU 利用率很低但工作卻一直無法完成的時候
優化和提升是兩回事當繼續提升的成本超過收益的時候應當停止優化
注意你的直覺但應該只根據直覺來指導解決問題的思路而不是用於確定系統的問題決策應當盡量基於數據而不是感覺
總體來說我們認為解決性能問題的方法首先是要澄清問題然後選擇合適的技術來解答這些問題如果你想嘗試提升服務器的總體性能那麼一個比較好的起點是將所有查詢記錄到日志中然後利用ptquerydigest 工具生成系統級別的剖析報告如果是要追查某些性能低下的查詢記錄和剖析的方法也會有幫助可以把精力放在尋找那些消耗時間最多的導致了糟糕的用戶體驗的或者那些高度變化的抑或有奇怪的響應時間直方圖的查詢當找到了這些壞查詢時要鑽取ptquerydigest 報告中包含的該查詢的詳細信息或者使用SHOW PROFILE 及其他諸如EXPLAIN 這樣的工具
如果找不到這些查詢性能低下的原因那麼也可能是遇到了服務器級別的性能問題這時可以較高精度測量和繪制服務器狀態計數器的細節信息如果通過這樣的分析重現了問題則應該通過同樣的數據制定一個可靠的觸發條件來收集更多的診斷數據多花費一點時間來確定可靠的觸發條件盡量避免漏檢或者誤報如果已經可以捕獲故障活動期間的數據但還是無法找到其根本原因則要麼嘗試捕獲更多的數據要麼嘗試尋求幫助
我們無法完整地測量工作系統但說到底它們都是某種狀態機所以只要足夠細心邏輯清晰並且堅持下去通常來說都能得到想要的結果要注意的是不要把原因和結果搞混了而且在確認問題之前也不要隨便針對系統做變動
理論上純粹的自頂向下的方法分析和詳盡的測量只是理想的情況而我們常常需要處理的是真實系統真實系統是復雜且無法充分測量的所以我們只能根據情況盡力而為使用諸如ptquerydigest 和MySQL 企業監控器的查詢分析器這樣的工具並不完美通常都不會給出問題根源的直接證據但真的掌握了以後已經足以完成大部分的優化診斷工作了
返回目錄高性能MySQL
編輯推薦
ASPNET MVC 框架揭秘
Oracle索引技術
ASP NET開發培訓視頻教程
數據倉庫與數據挖掘培訓視頻教程
From:http://tw.wingwit.com/Article/program/MySQL/201311/29691.html
