理解性能剖析
MySQL 的性能剖析（profile）將最重要的任務展示在前面但有時候沒顯示出來的信息也很重要可以參考一下前面提到過的性能剖析的例子不幸的是盡管性能剖析輸出了排名總計和平均值但還是有很多需要的信息是缺失的如下所示
值得優化的查詢（worthwhile queries）
性能剖析不會自動給出哪些查詢值得花時間去優化這把我們帶回到優化的本意如果你讀過Cary Millsap 的書對此就會有更多的理解這裡我們要再次強調兩點第一 一些只占總響應時間比重很小的查詢是不值得優化的根據阿姆達爾定律（Amdahls Law）對一個占總響應時間不超過% 的查詢進行優化無論如何努力收益也不會超過%第二如果花費了 美元去優化一個任務但業務的收入沒有任何增加那麼可以說反而導致業務被逆優化了 美元如果優化的成本大於收益就應當停止優化
異常情況
某些任務即使沒有出現在性能剖析輸出的前面也需要優化比如某些任務執行次數很少但每次執行都非常慢嚴重影響用戶體驗因為其執行頻率低所以總的響應時間占比並不突出
未知的未知
一款好的性能剖析工具會顯示可能的丟失的時間丟失的時間指的是任務的總時間和實際測量到的時間之間的差例如如果處理器的CPU 時間是 秒而剖析到的任務總時間是 秒那麼就有 毫秒的丟失時間這可能是有些任務沒有測量到也可能是由於測量的誤差和精度問題的緣故如果工具發現了這類問題則要引起重視因為有可能錯過了某些重要的事情即使性能剖析沒有發現丟失時間也需要注意考慮這類問題存在的可能性這樣才不會錯過重要的信息我們的例子中沒有顯示丟失的時間這是我們所使用工具的一個局限性
被掩藏的細節
性能剖析無法顯示所有響應時間的分布只相信平均值是非常危險的它會隱藏很多信息而且無法表達全部情況Peter 經常舉例說醫院所有病人的平均體溫沒有任何價值注假如在前面的性能剖析的例子的第一項中如果有兩次查詢的響應時間是 秒而另外 次查詢的響應時間是幾十微秒結果會怎樣？只從平均值裡是無法發現兩次 秒的查詢的要做出最好的決策需要為性能剖析裡輸出的這一行中包含的 次查詢提供更多的信息尤其是更多響應時間的信息比如直方圖百分比標准差偏差指數等
好的工具可以自動地獲得這些信息實際上ptquerydigest 就在剖析的結果裡包含了很多這類細節信息並且輸出在剖析報告中對此我們做了簡化可以將精力集中在重要而基礎的例子上通過排序將最昂貴的任務排在前面本章後面會展示更多豐富而有用的性能剖析的例子
在前面的性能剖析的例子中還有一個重要的缺失就是無法在更高層次的堆棧中進行交互式的分析當我們僅僅著眼於服務器中的單個查詢時無法將相關查詢聯系起來也無法理解這些查詢是否是同一個用戶交互的一部分性能剖析只能管中窺豹而無法將剖析從任務擴展至事務或者頁面查看（page view）的級別也有一些辦法可以解決這個問題比如給查詢加上特殊的注釋作為標簽可以標明其來源並據此做聚合也可以在應用層面增加更多的測量點這是下一節的主題
返回目錄高性能MySQL
編輯推薦
ASP NET開發培訓視頻教程
數據倉庫與數據挖掘培訓視頻教程
Oracle索引技術
From:http://tw.wingwit.com/Article/program/MySQL/201311/29719.html
