通過性能剖析進行優化
一旦掌握並實踐面向響應時間的優化方法就會發現需要不斷地對系統進行性能剖析（profiling）
性能剖析是測量和分析時間花費在哪裡的主要方法性能剖析一般有兩個步驟測量任務所花費的時間然後對結果進行統計和排序將重要的任務排到前面
性能剖析工具的工作方式基本相同在任務開始時啟動計時器在任務結束時停止計時器然後用結束時間減去啟動時間得到響應時間也有些工具會記錄任務的父任務這些結果數據可以用來繪制調用關系圖但對於我們的目標來說更重要的是可以將相似的任務分組並進行匯總對相似的任務分組並進行匯總可以幫助對那些分到一組的任務做更復雜的統計分析但至少需要知道每一組有多少任務並計算出總的響應時間通過性能剖析報告（profile report）可以獲得需要的結果性能剖析報告會列出所有任務列表每行記錄一個任務包括任務名任務的執行時間任務的消耗時間任務的平均執行時間以及該任務執行時間占全部時間的百分比性能剖析報告會按照任務的消耗時間進行降序排序
為了更好地說明這裡舉一個對整個數據庫服務器工作負載的性能剖析的例子主要輸出的是各種類型的查詢和執行查詢的時間這是從整體的角度來分析響應時間後面會演示其他角度的分析結果下面的輸出是用Percona Toolkit 中的pquerydigest（實際上就是著名的Maatkit 工具中的mkquerydigest）分析得到的結果為了顯示方便對結果做了一些微調並且只截取了前面幾行結果
Rank Response time Calls R/Call Item
==== ================ ===== ====== =======
% SELECT InvitesNew
% SELECT StatusUpdate
% SHOW STATUS
上面只是性能剖析結果的前幾行根據總響應時間進行排名只包括剖析所需要的最小列組合每一行都包括了查詢的響應時間和占總時間的百分比查詢的執行次數單次執行的平均響應時間以及該查詢的摘要通過這個性能剖析可以很清楚的看到每個查詢相互之間的成本比較以及每個查詢占總成本的比較在這個例子中任務指的就是查詢實際上在分析MySQL 的時候經常都指的是查詢
我們將實際地討論兩種類型的性能剖析基於執行時間的分析和基於等待的分析基於執行時間的分析研究的是什麼任務的執行時間最長而基於等待的分析則是判斷任務在什麼地方被阻塞的時間最長
如果任務執行時間長是因為消耗了太多的資源且大部分時間花費在執行上等待的時間不多這種情況下基於等待的分析作用就不大反之亦然如果任務一直在等待沒有消耗什麼資源去分析執行時間就不會有什麼結果如果不能確認問題是出在執行還是等待上那麼兩種方式都需要試試後面會給出詳細的例子
事實上當基於執行時間的分析發現一個任務需要花費太多時間的時候應該深入去分析一下可能會發現某些執行時間實際上是在等待例如上面簡單的性能剖析的輸出顯示表InvitesNew 上的SELECT 查詢花費了大量時間如果深入研究則可能發現時間都花費在等待I/O 完成上
在對系統進行性能剖析前必須先要能夠進行測量這需要系統可測量化的支持可測量的系統一般會有多個測量點可以捕獲並收集數據但實際系統很少可以做到可測量化大部分系統都沒有多少可測量點即使有也只提供一些活動的計數而沒有活動花費的時間統計MySQL 就是一個典型的例子直到版本 才第一次提供了PerformanceSchema其中有一些基於時間的測量點注而版本 及之前的版本沒有任何基於時間的測量點能夠從MySQL 收集到的服務器操作的數據大多是show status計數器的形式這些計數器統計的是某種活動發生的次數這也是我們最終決定創建Percona Server 的主要原因Percona Server 從版本 開始提供很多更詳細的查詢級別的測量點
雖然理想的性能優化技術依賴於更多的測量點但幸運的是即使系統沒有提供測量點也還有其他辦法可以展開優化工作因為還可以從外部去測量系統如果測量失敗也可以根據對系統的了解做出一些靠譜的猜測但這麼做的時候一定要記住不管是外部測量還是猜測數據都不是百分之百准確的這是系統不透明所帶來的風險
舉個例子在Percona Server 中慢查詢日志揭露了一些性能低下的原因如磁盤I/O等待或者行級鎖等待如果日志中顯示一條查詢花費 秒其中 秒在等待磁盤I/O那麼追究其他% 的時間花費在哪裡就沒有意義磁盤I/O 才是最重要的原因
返回目錄高性能MySQL
編輯推薦
ASP NET開發培訓視頻教程
數據倉庫與數據挖掘培訓視頻教程
Oracle索引技術
From:http://tw.wingwit.com/Article/program/MySQL/201311/29720.html
