1、效能優化簡介

什麼是效能？效能是完成某件任務所需要的時間度量，簡而言之，效能即響應時間。這是一個非常重要的原則。在實際工作中，如果我們把效能優化看作是提升每秒的查詢量，那麼這其實只是吞吐量的優化，吞吐量的提升可以看做效能優化的副產品。所以，如果我們將降低響應時間看做是效能優化，那我們就需要理解為什麼伺服器執行查詢會需要這麼多時間，從而引出我們效能優化的第二個原則：無法測量就無法有效的優化。所以第一步應該測量時間花在哪裡。

1.1 通過效能剖析進行優化

一旦掌握並實踐面向響應實踐的優化方法，就會發現需要不斷的對系統進行效能剖析。效能剖析是測量和分析時間花費在哪裡的主要方法。效能剖析一般有兩個步驟：測量任務所花費的時間；然後對結果進行統計和排序，將重要的任務排到前面。

1.2 理解效能剖析

MySQL的效能剖析（profile）將最重要的任務展示在前面，但有時候沒顯示出來的資訊也很重要。不幸的是，儘管效能剖析輸出 了排名、 總計和平均值，但還是有很多需要的資訊是缺失的，如下所示。

① 值得優化的查詢（worthwhile query) :效能剖析不會自動給出哪些查詢值得花時間去優化。

② 異常情況：某些任務即使沒有出現在效能剖析輸出的前面也需要優化。

③ 未知的未知：一款好的效能剖析工具會顯示可能的 “丟失的時間”。

④ 被掩藏的細節：效能剖析無撞顯示所有響應時間的分佈。

2、對應用程式進行效能剖析

對任何需要消耗時間的任務都可以做效能剖析， 當然也包括應用程式。實際上， 剖析應用程式一般比剖析資料庫伺服器容易， 而且回報更多。這裡我們推薦一個好的應用工具--New Relic，New Relic 會插入到應用程式中進行效能剖析， 將收集到的資料傳送到一個基於Web的 儀表盤， 使用儀表盤可以更容易利用面向響應時間的方怯分析應用效能。 這樣使用者只需 要考慮做那些正確的事情， 而不用考慮如何去做。 而且New Relic測量了很多使用者體驗相關的點， 涵蓋從Web瀏覽器到應用程式碼， 再到資料庫及其他外部呼叫。

3、剖析mysql查詢

對查詢進行效能剖析有兩種方式，每種方式都有各自的問題。可以剖析整個資料庫伺服器，這樣可以分析出哪些查詢是主要的壓力來源。定位到具體需要優化的查詢後，也可以鑽取下去對這些查詢進行單獨的剖析，分析哪些子任務是響應時間的主要消耗者。

3.1 剖析伺服器負載

伺服器端的剖析很有價值，因為在伺服器端可以有效地審計效率低下的查詢。定位和優化“壞”查詢能夠顯著地提升應用的效能，也能解決某些特定的難題，還可以降低伺服器的整體壓力。

捕獲mysql的查詢到日誌中：第一種是通過--processlist 選項不斷檢視SHOW FULL PROCESSLIST的輸出， 記錄查詢第 一次出現的時間和消失的時間。 某些情況下這樣的精度也足夠發現問題， 但卻無戰捕獲所有的查詢。第二種技術是通過抓取TCP網路包， 然後根據MySQL的客戶端／服務端通訊協議進行解析。

分析查詢日誌：強烈建議大家從現在起就利用慢查詢日誌捕獲伺服器上的所有查詢， 並且進行分析。 不要直接開啟整個慢查詢日誌進行分析， 這樣做只會浪費時間和金錢。 首先應該生成一個剖析報告， 如果需要， 則可以再檢視日誌中需要特別關注的部分。 自頂向下是比較好 的方式， 否則有可能像前面提到的， 反而導致業務的逆優化。這裡我們推薦使用pt-query-digest。

3.2 剖析單條查詢

在定位到需要優化的單條查詢之後，可以針對次查詢鑽探更多的資訊。確認為什麼會花費這麼長的時間執行，以及需要如何去優化。

使用show profile；使用show status；使用慢查詢日誌；使用performance schema；

總結：

1、我們認為定義效能最有效的方越是晌應時間。

2、如果無法測量就無陸有效地優化， 所以效能優化工作需要基於高質量、 全方位及完整的響應時間測量。 3、測量的最佳開始點是應用程式， 而不是資料庫。 即使問題出在底層的資料庫， 藉助良好的測量也可以很容易地發現問題。4、完整的測量會產生大量需要分析的資料， 所以需要用到剖析器。 這是最佳的工具，可以幫助將重要的問題冒泡到前面， 這樣就可以決定從哪裡開始分析會比較好。

5、優化和提升是兩回事。 當繼續提升的成本超過收益的時候， 應當停止優化。