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、優化和提升是兩回事。 當繼續提升的成本超過收益的時候， 應當停止優化。