????性能定義為，完成某件任務(wù)所需要的時(shí)間度量，換句話(huà)說(shuō)，性能即響應(yīng)時(shí)間。數(shù)據(jù)庫(kù)服務(wù)器的性能用查詢(xún)的響應(yīng)時(shí)間來(lái)度量，單位是每個(gè)查詢(xún)花費(fèi)的時(shí)間。
????性能優(yōu)化并不等于減少資源消耗，有時(shí)候消耗更多的資源能夠加快查詢(xún)速度，CPU利用率會(huì)上升。當(dāng)然CPU上升也可能是由于一些bug所造成的，因此不是一個(gè)很好的可度量目標(biāo)。
????性能優(yōu)化會(huì)產(chǎn)生一些副產(chǎn)品比如吞吐量?jī)?yōu)化，畢竟每秒查詢(xún)數(shù)增加意味著每條查詢(xún)執(zhí)行時(shí)間更短了。
性能剖析
????性能剖析是測(cè)量和分析時(shí)間花費(fèi)在哪里的方法，一般討論兩種類(lèi)型的剖析：基于執(zhí)行時(shí)間的分析和基于等待的分析。基于時(shí)間的分析研究的是什么任務(wù)的執(zhí)行時(shí)間最長(zhǎng)，而基于等待的分析是判斷任務(wù)在什么地方唄阻塞的時(shí)間最長(zhǎng)。
????進(jìn)行性能剖析之前，必須要先進(jìn)行測(cè)量，這需要系統(tǒng)能提供測(cè)量點(diǎn)來(lái)捕獲并收集數(shù)據(jù)，但大多數(shù)系統(tǒng)是沒(méi)有測(cè)量點(diǎn)的，即使有也只是提供一些活動(dòng)的計(jì)數(shù)，而沒(méi)有活動(dòng)花費(fèi)時(shí)間的統(tǒng)計(jì)，MySQL直到5.5版本后CIA提供了一些基于時(shí)間的測(cè)量點(diǎn)。當(dāng)然也不一定非要系統(tǒng)提供測(cè)量點(diǎn)，可以采用一些外部工具測(cè)量。
????以Percona Toolkit中的pt-query-digest為例，性能剖析會(huì)將最重要的任務(wù)展示在前面，進(jìn)行排行、總計(jì)和平均值等，但是還是會(huì)存在一些需要的信息缺失。比如：
值得優(yōu)化的查詢(xún)：不能自動(dòng)給出哪些查詢(xún)值得花時(shí)間優(yōu)化。強(qiáng)調(diào)兩點(diǎn)：一、一些占總響應(yīng)時(shí)間比重小的查詢(xún)是不值得優(yōu)化的；二、如果優(yōu)化成本大于收益也就不值得優(yōu)化。
異常情況：一些由于執(zhí)行次數(shù)少而低占比的查詢(xún)，單次查詢(xún)的響應(yīng)時(shí)間很大，這些屬于異常的查詢(xún)，也需要考慮優(yōu)化。
丟失的時(shí)間：任務(wù)的總時(shí)間和實(shí)際測(cè)量的時(shí)間之間存在差異，這類(lèi)問(wèn)題很難發(fā)現(xiàn)，一旦發(fā)現(xiàn)要引起重視，因?yàn)橛锌赡苠e(cuò)過(guò)某些重要的事情。即使性能剖析沒(méi)有發(fā)現(xiàn)丟失時(shí)間，也要考慮這類(lèi)問(wèn)題存在的可能性。
被掩藏的細(xì)節(jié)：性能剖析無(wú)法顯示所有響應(yīng)時(shí)間的分布，只相信平均值是很危險(xiǎn)的，這會(huì)隱藏很多信息。需要提供更多的信息，比如直方圖、百分比、標(biāo)準(zhǔn)差、偏差等。
????對(duì)應(yīng)用程序進(jìn)行性能剖析也很有必要，對(duì)系統(tǒng)的剖析建議都是自頂向下進(jìn)行，這樣可以追蹤自用戶(hù)發(fā)起到服務(wù)器響應(yīng)的整個(gè)流程。
????幸運(yùn)的是，我們只需要嵌入一個(gè)類(lèi)似New Relic的軟件服務(wù)產(chǎn)品到系統(tǒng)中，就可以很好的定位分析到我們要處理的性能問(wèn)題。
剖析MySQL查詢(xún)
????剖析服務(wù)器負(fù)載可以很有效地審計(jì)效率低下的查詢(xún)。使用慢查詢(xún)?nèi)罩臼情_(kāi)銷(xiāo)最低，精度最高的測(cè)量查詢(xún)時(shí)間的工具。
????書(shū)中建議使用慢查詢(xún)?nèi)罩居涗洸樵?xún)或者使用pt-query-digest分析tcpdump的結(jié)果，是兩種比較好的方式來(lái)查詢(xún)要優(yōu)化的語(yǔ)句的細(xì)節(jié)。
????當(dāng)定位到需要查詢(xún)優(yōu)化的單條查詢(xún)后，可以針對(duì)此查詢(xún)”鉆取“更多的信息，確認(rèn)為什么花費(fèi)這么長(zhǎng)的時(shí)間執(zhí)行，以及需要如何去優(yōu)化。在官方MySQL版本下，一般使用以下幾種方法來(lái)剖析查詢(xún)：（推薦一個(gè)實(shí)驗(yàn)的例子：https://blog.csdn.net/zuozewei/article/details/86681249）
使用Explain執(zhí)行計(jì)劃：該命令使用十分簡(jiǎn)單，只需要“EXPLAIN+SQL語(yǔ)句”即可，該命令可以對(duì)SELECT語(yǔ)句進(jìn)行分析，并輸出SELECT執(zhí)行的詳細(xì)信息，以供開(kāi)發(fā)、測(cè)試人員針對(duì)性的優(yōu)化。
使用SHOW PROFILE：該命令是在 MySQL5.1 以后引入的，來(lái)源于開(kāi)源社區(qū)中的 Jeremy Cole 的貢獻(xiàn)。在 MySQL 數(shù)據(jù)庫(kù)中默認(rèn)是禁用的，可以通過(guò)服務(wù)器變量在會(huì)話(huà)（連接）級(jí)別動(dòng)態(tài)地修改。然后，在服務(wù)器上執(zhí)行的所有語(yǔ)句，都會(huì)測(cè)量其耗費(fèi)的時(shí)間和其它一些查詢(xún)執(zhí)行狀態(tài)變更相關(guān)數(shù)據(jù)。但是，盡管報(bào)告可以幫助我們定位到哪些活動(dòng)花費(fèi)了最多的時(shí)間，但并不會(huì)告訴我們?yōu)槭裁磿?huì)這樣，要弄清楚為什么會(huì)發(fā)費(fèi)這么多時(shí)間，就需要深入下去，繼續(xù)剖析其子任務(wù)。
使用SHOW STATUS：該命令返回一些計(jì)數(shù)器，既有服務(wù)器級(jí)別的全局計(jì)時(shí)器，也有基于某個(gè)連接的會(huì)話(huà)級(jí)別的計(jì)數(shù)器。該命令是一個(gè)很有用的工具，但并不是一款剖析工具。雖然無(wú)法提供基于時(shí)間的統(tǒng)計(jì)，但是執(zhí)行查詢(xún)完后觀(guān)察某些計(jì)數(shù)器的值還是很有幫助的。我們可能注意到通過(guò) Explain 執(zhí)行計(jì)劃也可以獲得大部分相同的信息，但是 Explain 是通過(guò)估計(jì)得到的結(jié)果，而通過(guò)計(jì)數(shù)器則是實(shí)際的測(cè)量結(jié)果。
慢查詢(xún)?nèi)罩荆涸摴δ苄枰薷呐渲梦募?lái)生效，慢查詢(xún)的語(yǔ)句可以在設(shè)置的slow.log中查詢(xún)到。
診斷間歇性問(wèn)題
????間歇性問(wèn)題比如系統(tǒng)偶爾停頓或者慢查詢(xún)，很難診斷。這些幻影問(wèn)題只在沒(méi)有注意到時(shí)才發(fā)生，而且無(wú)法確認(rèn)如何重現(xiàn)，診斷這樣的問(wèn)題往往要花費(fèi)很多時(shí)間。
????盡量不要使用試錯(cuò)的方式來(lái)解決問(wèn)題，這種方式風(fēng)險(xiǎn)很大，可能導(dǎo)致更壞的結(jié)果，而且這種方式也很低效，好的做法是使用正確的測(cè)量方式來(lái)定位錯(cuò)誤。
????要解決這類(lèi)問(wèn)題，首先要定位是單條查詢(xún)問(wèn)題還是服務(wù)器問(wèn)題。如果是服務(wù)器問(wèn)題，那么需要對(duì)MySQL內(nèi)部機(jī)制更加了解才能診斷出來(lái)問(wèn)題，當(dāng)然很多問(wèn)題也可以通過(guò)升級(jí)到MySQL新版本來(lái)解決（如果沒(méi)有足夠的理由不要嘗試升級(jí)）。
????如何判斷單條還是服務(wù)器問(wèn)題，使用下面幾種技術(shù)：
1. 使用SHOW GLOBAL STATUS：該方法就是以較高的頻率比如一秒執(zhí)行一次SHOW GLOBAL STATUS命令捕獲數(shù)據(jù)，問(wèn)題出現(xiàn)時(shí)，可以通過(guò)某些計(jì)數(shù)器（比如Threads_running、Threads_connected、Questions和Queries）的“尖刺”或者“凹陷”來(lái)發(fā)現(xiàn)，這個(gè)方法比較簡(jiǎn)單，而且對(duì)服務(wù)器影響也很小。
2. 使用SHOW PROCESSLIST：該方法不停捕獲SHOW PROCESSLIST的輸出，來(lái)觀(guān)察是否有大量線(xiàn)程處于不正常的狀態(tài)或者有其他不正常的特征。也可以直接查詢(xún)INFORMATION_SCHEMA中的PROCESSLIST表，或者使用innotop工具以較高的頻率刷新，以觀(guān)察屏幕上出現(xiàn)的不正常查詢(xún)堆積。
3. 使用查詢(xún)?nèi)罩荆洪_(kāi)啟慢查詢(xún)?nèi)罩静⒃O(shè)置long_query_time為0，就可以捕獲所有的查詢(xún)語(yǔ)句。
4. 理解發(fā)現(xiàn)的問(wèn)題：可視化數(shù)據(jù)。
????當(dāng)出現(xiàn)間歇性問(wèn)題時(shí)，需要盡可能多地收集所有數(shù)據(jù)，而不只是問(wèn)題出現(xiàn)時(shí)的數(shù)據(jù)。雖然這樣會(huì)收集大量的診斷數(shù)據(jù)，但總比真正能夠診斷問(wèn)題的數(shù)據(jù)沒(méi)有被收集到的情況要好。收集前，需要一個(gè)可靠且實(shí)時(shí)的‘觸發(fā)器“，也就是區(qū)分什么時(shí)候問(wèn)題出現(xiàn)的方法以及一個(gè)收集診斷數(shù)據(jù)的工具。
????可收集的數(shù)據(jù)包括系統(tǒng)的狀態(tài)、CPU利用率、磁盤(pán)使用率和可用空間、ps的輸出采樣、內(nèi)存利用率，以及可以從MySQL獲得的信息，如SHOW STATUS、SHOW PROCEESLIST和SHOW INNODB STATUS。
總結(jié)
????解決性能問(wèn)題的方法，首先是澄清問(wèn)題，然后選擇合適的技術(shù)來(lái)解答這些問(wèn)題。如果想提升服務(wù)器總體性能，好的起點(diǎn)是將所有查詢(xún)記錄到日志中，然后利用工具（pt_query_digest）生成系統(tǒng)級(jí)別的剖析報(bào)告。如果是要追查某些性能低下的查詢(xún)，記錄和剖析額方法也會(huì)有幫助。可以把精力放在尋找那些消耗時(shí)間最多的，找到這些查詢(xún)鉆取報(bào)告中包含的該查詢(xún)的詳細(xì)信息，或者使用SHOW PROFILE及其他諸如EXPLAIN這樣的工具。
????如果找不到查詢(xún)性能低下的原因，那么可能遇到了服務(wù)器級(jí)別的性能問(wèn)題，這時(shí)可以較高精度測(cè)量和繪制服務(wù)器狀態(tài)計(jì)數(shù)器的細(xì)節(jié)信息。如果通過(guò)這樣的分析重現(xiàn)了問(wèn)題，則應(yīng)該通過(guò)同樣的數(shù)據(jù)制定一個(gè)可靠的觸發(fā)條件來(lái)收集更多的診斷數(shù)據(jù)，多花時(shí)間來(lái)確定可靠的觸發(fā)條件盡量避免漏檢誤報(bào)。
????理論上純粹的自頂向下的方法分析和詳盡的測(cè)量只是理想的情況，而我們常常需要處理的是真實(shí)系統(tǒng)，需要按實(shí)際的情況來(lái)處理。
