MySQL report分析

基本信息

mysql當(dāng)前的版本豹休，運(yùn)行的時間朋其，以及當(dāng)前系統(tǒng)時間。 MySQL服務(wù)器版本信息表明MySQL服務(wù)器包含和不包含哪些特點(diǎn)看锉。 MySQL服務(wù)器運(yùn)行時間表明報告價值的代表性省有。服務(wù)器運(yùn)行時間對于評估報告是很重要的，因?yàn)槿绻?wù)器不運(yùn)行幾個小時的話，輸出報告有可能存在曲解和誤導(dǎo)性临梗。有時甚至運(yùn)行幾個小時時間都是不夠的，比如稼跳，MySQL服務(wù)器運(yùn)行了午夜的6個小時幾乎沒有業(yè)務(wù)訪問過盟庞。最理想的情況是，MySQL服務(wù)器運(yùn)行一天之后再運(yùn)行mysqlreport來輸出報告汤善，這樣報告的代表價值要比系統(tǒng)剛運(yùn)行時要好的多什猖。 在性能場景的運(yùn)行周期前啟動mysql，在性能場景結(jié)束后生成mysqlreport會比較有用红淡。比如此例中不狮，場景運(yùn)行了1小時后執(zhí)行了mysqlreport。

索引報表

說明mysql當(dāng)前索引緩沖區(qū)的使用率在旱，如果過高摇零，則需要調(diào)整keybuffersize的大小了。write hit及read hit分別說明了寫索引和讀索引的效率桶蝎。 keybuffersize 對MyISAM引擎的性能有很大的影響驻仅。 不能表明是否MySQL服務(wù)器索引是否良好，但是能夠指示shared key buffer（共享索引緩存）是否被充分利用登渣。本部分僅能顯示用于MyISAM表的共享索引緩存噪服，其他的緩存并沒有顯示。

MySQL服務(wù)器的首要問題：索引緩存用了多少胜茧？如果它并沒有被用很多粘优，說明狀況比較好，MySQL僅僅是在需要時分配了用于索引緩存的系統(tǒng)RAM。也就是說敬飒，如果索引緩存設(shè)置為512M邪铲，那么MySQL不是在系統(tǒng)開始時就分配的512M內(nèi)存，MySQL僅僅會當(dāng)需要時才會分配512M那么多无拗！

Buffer used带到，顯示的就是MySQL曾經(jīng)一次分配的最大的數(shù)量。實(shí)際上英染，MySQL實(shí)際的使用量會少揽惹，也有可能多于這個數(shù)。MySQL稱之為“高水位（high water mark）”四康。這一指標(biāo)通常說明MySQL的配置指標(biāo)中keybuffersize是否足夠大搪搏。?如果報告的此行指示，MySQL已經(jīng)占用了索引緩存的80%到90%闪金，那么keybuffersize的參數(shù)就應(yīng)該增大疯溺。?注意，這一行的指標(biāo)是不可能超過95%的哎垦〈涯郏考慮到mysqlreport無法計(jì)算一些內(nèi)部數(shù)據(jù)結(jié)構(gòu)對索引緩存的占用情況，所以漏设，95%通常也就是表示為100%墨闲。 在本例子中，MySQL利用了8M緩存的3k空間郑口，所以索引緩存是基本都沒有用到鸳碧。 在本例中，keybuffersize=8388608犬性，即8M瞻离。

請注意，這里所指的 Key Buffer 是指MyISAM Storage Engine 所使用的 Shared Key Buffer乒裆，InnoDB 所使用的 Key Buffer 并不包含在內(nèi)琐脏。 MySQL Server 的 Buffer 大略可分為二種：

Global Buffer：由所有 Client 所共享的 Buffer keybuffer innodbbufferpool innodblogbuffer innodbadditionalmempool net_buffer ...等等

測試學(xué)習(xí)資料分享群：747981058

Thread Buffer：個別的 Connection 所需占用的 Buffer 例如： sortbuffer myisamsortbuffer readbuffer joinbuffer readrnd_buffer ...等等。

計(jì)算 Server 至少需使用的總內(nèi)存數(shù)量的方式為： minmemoryneeded = globalbuffer + (threadbuffers * max_connection) 關(guān)于 MySQL 的 Cache 機(jī)制有一點(diǎn)需要特別注意缸兔，MyISAM Storage Engine 將每個 table 分成三個檔案儲存在硬盤之中日裙，例如若有一個數(shù)據(jù)表的名稱為 example，那么就會在硬盤上發(fā)現(xiàn) example.FRM, example.MYD,example.MYI 等三個檔案惰蜜。這三個檔案所儲存的數(shù)據(jù)如下： FRM： 儲存這個數(shù)據(jù)表的結(jié)構(gòu) MYD： Row Data昂拂，也就是你存在 example 數(shù)據(jù)表里的數(shù)據(jù) MYI： 此數(shù)據(jù)表的索引接下來是重點(diǎn)： 當(dāng)MySQL要Cache某個資料表時，MySQL只會Cache索引抛猖，也就是MYI檔案格侯，而Row Data(.MYD)則是交由操作系統(tǒng)來負(fù)責(zé) Cache鼻听。 到底 Key Buffer 要設(shè)定多少才夠呢？如前所述联四，MySQL只會Cache 索引(.MYI)撑碴，因此只要將數(shù)據(jù)庫中所有的 MYI檔案加總起來，你就會知道大概要設(shè)為多少朝墩。

這一行指示MySQL在生成報告時占用索引緩存的情況（4.1.2和以后的版本有效醉拓，因?yàn)镵eyblocksunused是在4.1.2以后才增加的。）收苏。如果前一行表示是一個高水位指示亿卤，那么這一行的占用量應(yīng)該是小于或等于上一行的高水位。有時也會高于高水位指示鹿霸，這是不是MySQL的Bug目前還不得而知排吴。不管怎樣，這一行和前一行的結(jié)果能夠很好地指示keybuffersize的參數(shù)設(shè)置的是不是足夠大懦鼠。 在本例子中钻哩，MySQL服務(wù)器狀態(tài)就不太好，占用了8M肛冶，是索引緩存的100%街氢，已經(jīng)是全部的空間了。

從以上兩個數(shù)據(jù)就可以看到的是淑趾，mysql每一次分配的key buffer都不大，最大的也只有3K忧陪，但整個key buffer占用卻已經(jīng)達(dá)到100%了扣泊，所以還是要增加key buffer size才行。

索引（keys）是使用固有RAM分區(qū)的嘶摊。這一行延蟹，Write hit，顯示了索引寫入的效率（這是個百分比比率值叶堆，分子是索引寫入硬盤的量阱飘，分母是索引寫入緩存的量）。索引寫入命中率沒有一個標(biāo)準(zhǔn)值虱颗。索引寫入命中率依賴于MySQL服務(wù)器基本執(zhí)行的是哪種語句沥匈。如果MySQL主要執(zhí)行的是updates或者inserts，那么索引寫入命中率可能接近0%是可接受的忘渔；如果MySQL主要執(zhí)行的是selects高帖，那么索引寫入命中率可能90%或更多是可接受的。一個負(fù)數(shù)百分比表示MySQL寫入索引到硬盤多于寫入緩存畦粮，這樣通常會很慢散址、不合理的乖阵、不可接受的。 最好描述索引寫入命中率的方法预麸，就是需要你知道MySQL服務(wù)器主要執(zhí)行哪些語句瞪浸，DMS報告（Lines 17-22）能夠幫助解決這一問題。結(jié)合Questions部分的DMS里insert的數(shù)據(jù)量吏祸，可知对蒲，在這個場景執(zhí)行的過程中，主要是insert語句犁罩，所以這里的索引寫入命中率接近0%的齐蔽。

計(jì)算公式：Write hit = MySQL將索引寫入硬盤的次數(shù) / MySQL將索引寫入RAM的次數(shù)

比索引寫入命中率更重要的是索引讀取命中率（key read hit）。這一行描述了索引讀取的效率（這是個百分比比率值床估，分子是索引讀取硬盤的量含滴，分母是索引讀取緩存的量）。索引讀取命中率應(yīng)該低于99%丐巫。 過低的百分比表明這會是一個問題谈况。一個低索引命中百分比通常可能是索引空間太小了递胧。索引空間是為了避免MySQL裝載過多的索引到內(nèi)存中碑韵，當(dāng)這種情況發(fā)生時，MySQL會恢復(fù)從硬盤讀取索引缎脾，這就會使得硬盤相當(dāng)慢而且會使索引無效祝闻。 通常來講，開始運(yùn)行MySQL的前1-2個小時遗菠，這一行的值會低于99%联喘，經(jīng)過1-2個小時以后，取值就會接近99%辙纬。

Read hit = MySQL從硬盤讀取索引的次數(shù) / MySQL從RAM讀取索引的次數(shù)

操作報表

操作報表的第一行表示了MySQL回應(yīng)了所有問題的總數(shù)和更新時間內(nèi)的平均回應(yīng)率豁遭。從下面的數(shù)據(jù)可以看到，每秒mysql的操作是3.2k次（QPS）贺拣，但是有多少完成了蓖谢，就要看下面的幾行數(shù)據(jù)了。?（這里需要說明的是譬涡，“Questions（操作）”是被響應(yīng)的闪幽，而“（Queries查詢）”是被執(zhí)行的。mysqlreport可以分辨出“操作”和查詢涡匀，特別是在“操作數(shù)報告”中沟使。“操作”是每個和各種對MySQL服務(wù)器的請求渊跋，這包含了SQL查詢和MySQL特定的命令和協(xié)議通信腊嗡，查詢是僅包含SQL查詢：SELECT, UPDATE等）

所有的“操作”可分為5類：數(shù)據(jù)操作語句（DMS）着倾、查詢緩存命中率（QC Hits）、COMQUIT燕少、其他通信命令和未知卡者。這5個分類是動態(tài)顯示的。mysqlreport按照他們的總次數(shù)降序排列客们。這個子報告能夠明顯的表示出MySQL在忙著干什么崇决。理想情況下，MySQL應(yīng)該忙于DMS 或者QC Hits底挫，因?yàn)檫@些行為時真正完成某些事情的恒傻。COMQUIT，Com和Unknown類別是必要的建邓，但是處于次要地位盈厘。 在進(jìn)一步解釋每一類之前，需要說明的是這部分子報告第三列表明該列值占總“操作”請求數(shù)的百分比官边，“操作”部分的其他子報告也是如此沸手。在例子中，DMS數(shù)占總操作數(shù)的82.84%是正常示數(shù)注簿。 Data manipulation statements（DMS）包括SELECT契吉，INSERT，REPLACE捐晶，UPDATE和DELETE⊥纾基本上惑灵，DMS是MySQL數(shù)據(jù)庫干的最有用的，因此恩袱，DMS應(yīng)該是MySQL做的最多的泣棋。DMS子報告會詳細(xì)顯示胶哲。 QC Hits（Query Cache Hits） 是MySQL查詢執(zhí)行過程中畔塔，通過查詢緩存補(bǔ)償，而不是實(shí)際執(zhí)行的操作數(shù)鸯屿。具有一個較高的QC Hits數(shù)是令人期待的澈吨，因?yàn)镼C的返回是非常快的寄摆。但是谅辣，完成有效地QC緩存是非常困難的。這在后面的Query Cache Report中的Insrt:Prune和Hit:Insert部分將深入解釋婶恼。 在例子中桑阶，QC Hits是沒有顯示的柏副，說明在這個report期間沒有select語句。 COMQUIT 是個可以忽略的無關(guān)緊要的參數(shù)蚣录，它包含到報告中為了保證完整性割择。 Com_ 表示MySQL處理的各種命令，通常都是協(xié)議相關(guān)的萎河。理想情況下荔泳，在這個指標(biāo)應(yīng)當(dāng)比較低，因?yàn)楫?dāng)比較高時虐杯，說明MySQL忙而無用玛歌。該分類參數(shù)過高，則表示一些怪異的問題擎椰，后面在Com_將詳細(xì)討論支子。 Unknown 是一個推測的目錄。理想情況下确憨，前四部分的總和應(yīng)該是等于全部“操作”數(shù)量译荞，但通常不相等。這是因?yàn)榇嬖谝恍㎝ySQL的操作休弃，增加了操作計(jì)數(shù)器吞歼，但是并沒有表現(xiàn)在單獨(dú)的指標(biāo)上。 這一行會動態(tài)顯示為"+Unknown"或者"-Unknown"塔猾。"+Unknown"表示存在更多的操作數(shù)篙骡，比mysqlreport計(jì)算的多；"-Unknown"表示mysqlreport計(jì)算的數(shù)比所有的統(tǒng)計(jì)數(shù)少丈甸。

指示了MySQL執(zhí)行的慢查詢數(shù)目有多少糯俗。影響“Slow”指標(biāo)的系統(tǒng)參數(shù)longquerytime，這一參數(shù)默認(rèn)值為10s睦擂。很多人認(rèn)為10s是在數(shù)據(jù)庫時間中時一個恒定值得湘，longquerytime最好設(shè)置為1或者毫秒級單位（毫秒設(shè)置在MySQL的新版本中支持） longquerytime，這一參數(shù)值只有慢查詢之后才會顯現(xiàn)出來顿仇。在mysqlreport v3.5以后淘正，該參數(shù)支持：秒、毫秒臼闻、微妙鸿吆。在某些情況下，該參數(shù)由于顯示寬度8個字母的限制述呐。例如惩淳，longquerytime的參數(shù)值'999.999 ms'截?cái)喑?999.999 '，'10.000100 s'截?cái)喑?10.0001 '乓搬。 理想情況下思犁，慢查詢的統(tǒng)計(jì)應(yīng)該為0代虾，但是通常也會有一些慢查詢的存在。一般來說激蹲，慢查詢的比率（第三列）占整個操作數(shù)的0.05或更低褐着。當(dāng)有很多慢查詢（第一列），這是的比率值就會顯示出問題托呕。這一行還增加了一列：DMS操作數(shù)百分比含蓉。對于慢查詢，0是最好的项郊，這一列在DMS子報告中更加有用馅扣。 最后一列，Log着降，表示慢查詢?nèi)罩竟δ荛_啟還是關(guān)閉（通過設(shè)置logslowqueries參數(shù)）差油。慢查詢?nèi)罩就ǔＪ谴蜷_的。

DMS子報告任洞，和DTQ子報告一樣蓄喇，第一列是按照降序排列的,第二列是按每秒計(jì)算的結(jié)果，第三列表明該列值占總數(shù)的百分比交掏。表示了前文所提到數(shù)據(jù)操作數(shù)（SELECT妆偏、INSERT等）。 第一行顯示的和DTQ報告中的顯示一樣的盅弛。 這一子報告顯示MySQL數(shù)據(jù)庫是哪一種類的數(shù)據(jù)庫：是查詢負(fù)荷高钱骂、還是插入負(fù)荷高、還是其他的挪鹏。MySQL服務(wù)器都是傾向于查詢負(fù)荷高（SELECT heavy）见秽。了解是哪種類型的MySQL數(shù)據(jù)庫有利于理解其他的報告值。例如讨盒，一個插入負(fù)荷高的服務(wù)器解取，其寫入率會接近為1.0，這種類型的數(shù)據(jù)庫鎖表報告值也會偏高返顺，這類數(shù)據(jù)庫適合采用InnoDB類型表禀苦；一個查詢負(fù)荷高的數(shù)據(jù)庫，就會表現(xiàn)出讀取率為1和一個較低的表鎖值创南，這種類型的數(shù)據(jù)庫需要采用查詢緩存伦忠，適合于采用MyISAM表省核。 在這個例子中稿辙，服務(wù)器是一個插入高的數(shù)據(jù)庫。很明顯气忠，這個數(shù)據(jù)庫面向插入事務(wù)邻储。知道數(shù)據(jù)庫類型就有利于數(shù)據(jù)庫參數(shù)的優(yōu)化赋咽。

Com子報告和其他子報告一樣分類排序。這部分子報告的內(nèi)容不同于服務(wù)器到服務(wù)器命令吨娜，因?yàn)槊恳恍兄甘镜腃om指標(biāo)都是表現(xiàn)的MySQL協(xié)議的命令脓匿，你可以參考MySQL的幫助文檔理解這部分概念。 大部分的條目名稱都是很直觀的宦赠，比如Comchangedb陪毡。 這部分指標(biāo)當(dāng)DTQ子報告中的Com最高時才起作用，此時表明MySQL正忙于“程序事務(wù)”而不是SQL查詢事務(wù)勾扭。舉個例子毡琉，一臺服務(wù)器的Comrollback指標(biāo)很高。rollback發(fā)生在事務(wù)處理失敗的時候妙色。服務(wù)器的每一次事務(wù)處理都失敗桅滋，很顯然，服務(wù)器是有問題的身辨。在沒有mysqlreport的情況下丐谋，很明顯是不可能分辨出服務(wù)器的這些問題的。 大部分服務(wù)器煌珊，Com_子報告顯示沒有異常号俐，但是時常地檢查該部分報告是很有必要的。

查詢和排序報表

Scan 指的是有多少 SELECT statements 造成 MySQL 需要進(jìn)行 Full Table Scan定庵。Full Join 的意思與 Scan 差不多萧落，但它是適用在多個 Tables 相互Join 在一起的情況。這二種情況的執(zhí)行效能都非常的差洗贰，因此原則上你會希望這兩個數(shù)值越低越好找岖。但這也不是絕對的，仍然要考慮實(shí)際的情況敛滋，例如雖然Server 有很高比例的 Scan许布，但若這些 Scan 都是針對一些只有幾十筆數(shù)據(jù)的 table，那么相對而言它依然是十分有效率的绎晃；但反之蜜唾，若這些 Scan 是針對具有上百萬筆數(shù)據(jù)的 table，那么就會嚴(yán)重影響系統(tǒng)效能庶艾。

查詢緩存報表

查詢緩存的目的很簡單袁余，將select查詢的結(jié)果緩存在內(nèi)存中，以供下次直接獲取咱揍。在這個場景中緩存查詢是沒有開啟的颖榜。

在查詢?yōu)橹鞯臄?shù)據(jù)庫的由要開啟緩存查詢，并且要配置合理的查詢緩存大小。

但是掩完，查詢緩存有一個需要注意的問題噪漾，那就是緩存過期策略，MySQL采用的機(jī)制是且蓬，當(dāng)一個數(shù)據(jù)表有更新操作（比如update或者insert）后欣硼，那么涉及這個表的所有查詢緩存都會失效。這的確令人比較沮喪恶阴，但是MySQL這樣做是不希望引入新的開銷而自找麻煩诈胜，所以“寧可錯殺一千，不可放過一個”冯事。這樣一來耘斩，對于select和update混合的應(yīng)用來說，查詢緩存反而可能會添亂

比如說如下mysqlreport中查詢緩存的報告：

如果你的應(yīng)用中對于密集select的數(shù)據(jù)表很少更新桅咆，很適合于使用查詢緩存括授。 Block Fragmnt這個數(shù)值越高表示 Query Cache 的碎片狀況越嚴(yán)重，通常它會界于 10%~20% 之間岩饼。在此范例中 Block Fragmnt 為 100%荚虚，這是不可接受的情況〖耄可以調(diào)整 querycacheminresunit 的值來降低Block Fragmnt版述。

再來分析另一個例子中的QC情況：

Hits 是這三個數(shù)值中最重要的一項(xiàng)，因?yàn)樗赋鲇卸嗌?SELECT statements 是可直接從 Query Cache 里面取得所需的信息寞冯，此數(shù)值 越高就越好渴析。Inserts 和 Prunes 最好是從比值來觀察比較容易理解。雖然 Prunes 的值偏高可能代表著Query Cache 設(shè)得不夠大吮龄，但并不一定是如此俭茧。在上例中只有 55% 的 Query Cache 被使用，有著相對而言算低的fragmentation 值漓帚，但 Prunes 值偏高母债，Prunes 的值(16/s)是 QC Hits 的兩倍〕⒍叮可以想象這臺Server 的 Query Cache 是一顆蘋果樹毡们，它的樹枝被剪去的速度比你采收蘋果的速度還快。 Insert 與 Prune 的比值可顯示 Query Cache 的揮發(fā)性昧辽。在一個高度穩(wěn)定的 Query Cache 中衙熔，Insrt 的值應(yīng)該要高于 Prune 的值；反之搅荞，在一個揮發(fā)性較高(較不穩(wěn)定)的 Query Cache 中红氯，這個比值將會是 1:1 或是偏重在 Prune 那方框咙，這表示 Query Cache 中的數(shù)據(jù)有可能在使用到之前就已經(jīng)被清了。我們會希望擁有一個穩(wěn)定的 Query Cache脖隶，因?yàn)榉€(wěn)定的 Query Cache 表示那些被 Cache 在 Query Cache 中的資料會常被用到。高揮發(fā)性(較不穩(wěn)定)的Query Cache 代表兩件事情：第一暇检，Query Cache 設(shè)得太小产阱，需要加大。第二块仆，MySQL 正試圖要 cache 所有的東西构蹬，甚至是那些其實(shí)并不需要 cache 的數(shù)據(jù)。若是第一種狀況悔据，只要單純的加大 Query Cache 即可庄敛。若是第二種情況，可能是 MySQL 試圖要去 cache 所有可以 cache 的數(shù)據(jù)科汗，你可以使用 SQLNOCACHE 來明確的告訴 MySQL 什么資料是你不想要 cache 的藻烤。 Hit 與 Insert 的比值代表著 Query Cache 的有效性，理想的情況是我們新增了一些 Qeury 到Query Cache 中头滔，然后希望得到許多 Hits怖亭。因此若是這個 Query Cache 是有效率的，那么該比值應(yīng)該要偏重在左方坤检。若比值是偏重在 Insert 那方兴猩，那么這個 Query Cache 的揮發(fā)性就太高了≡缧考慮以下這個比值倾芝，若 Hit:Insert 為 1:1，那就表示Query Cache 中的數(shù)據(jù)只使用了一次就被清除掉了箭跳，換句話說漂彤，我們放進(jìn)去的數(shù)據(jù)比我們從里面拿出來的數(shù)據(jù)還多，這樣一來就失去了使用Query Cache 的意義怀泊±烁回想我們前面所提過的，雖然在本范例中 QC Hit 在全部的 Questions 中占了很高的比例逝段，但實(shí)際上我們可以發(fā)現(xiàn) QC 的有效性其實(shí)是很低的(Hit:Insert 的比值偏重在 Insert 那方)垛玻。若造成這個現(xiàn)象的原因是 MySQL 正試圖cache 所有的東西，那么將 Cache 模式改為 DEMAND 或許可以解決此問題奶躯。

表鎖報表

Waited表示有多少次查詢需要等待表鎖定帚桩；Immediate表示有多少次查詢可以立即獲得表鎖定，同時后面還有一個比例嘹黔，表示等待表鎖定的查詢次數(shù)占所有查詢次數(shù)的百分比账嚎，這里是0.00%莫瞬，非常好，但為什么這么低呢郭蕉？這需要了解MyISAM的表鎖定機(jī)制疼邀。 MyISAM的表鎖定可以允許多個線程同時讀取數(shù)據(jù)，比如select查詢召锈，它們之間是不需要鎖等待的旁振。但是對于更新操作（如update操作），它會排斥對當(dāng)前表的所有其他查詢涨岁，包括select查詢拐袜。除此之外，更新操作有著默認(rèn)的高優(yōu)先級梢薪，這意味著當(dāng)表鎖釋放后蹬铺，更新操作將先獲得鎖定，然后才輪到讀取操作秉撇。也就是說甜攀，如果有很多update操作排著長隊(duì)，那么對當(dāng)前表的select查詢必須等到所有的更新都完成之后才能開始琐馆。 舉例如下：

這個部份包含了兩項(xiàng)信息：第一項(xiàng)是 Waited赴邻，代表 MySQL 需要等待以取得 table lock 的次數(shù)。第二項(xiàng)是 Immediate啡捶，表示MySQL 不需要等待即可立刻取得 table lock 的次數(shù)姥敛。對數(shù)據(jù)庫來說『等待』幾乎可以肯定是一件很不好的事情，因此 Waited 的值應(yīng)該要越小越好瞎暑。最具有代表性的是第三個字段 (Waited 占所有 table lock 的百分比)彤敛，這個數(shù)值應(yīng)該要小于 10%，大于這個值就表示table/query 的索引設(shè)計(jì)不良或是有過多的 Slow Query了赌。

從下面的數(shù)據(jù)來看墨榄，在場景執(zhí)行期間就沒有發(fā)生過鎖表的情況。

表信息報表

第一是 Open勿她，顯示目前正開啟的 table 數(shù)量袄秩、總共可開啟的最大數(shù)量，以及 Table Cache 的使用狀況逢并。第二是Opend之剧，表示截至目前為止 MySQL 總共開啟過的 Table 數(shù)量，以及除上 Uptime 后的比值砍聊。這里有兩件事值得注意：首先是Table Cache 的使用狀況背稼，100% 的 Table Cache 使用率并不是一件壞事但你可以試著調(diào)大 Table Cache 以增進(jìn)效能。第二是 MySQL 開啟 Table 的平均速率玻蝌，若這個值很高則表示的 table_cache 設(shè)得太小了蟹肘，需要調(diào)大一些词疼。一般來說， MySQL 開啟 Table 的平均速率最好是小于 1/s帘腹。但大于這個數(shù)值也不一定就是壞事贰盗，有些調(diào)校良好且運(yùn)作的十分有效率的MySQL Server 其值為 7/s 并使用了 100% 的 Table Cache。

連接報表

Connections Report 所代表的意義與 Tables Report 相似阳欲，請各位以此類推舵盈。比較需要注意的是：若你發(fā)現(xiàn) Connections 的使用率接近 100%，也許你會想調(diào)大 maxconnections 的值以允許MySQL 的 Client 建立更多連接胸完。然而书释，這通常是一種錯誤翘贮。常成蘅可以發(fā)現(xiàn)很多網(wǎng)絡(luò)上的數(shù)據(jù)會教我們要調(diào)大 maxconnections，但卻從來沒有給一個明確的理由狸页。事實(shí)上锨能，maxconnections 的默認(rèn)值(100)，就算是對于負(fù)載十分沉重但有良好調(diào)校過的 Server 都已十分足夠芍耘。MySQL 對于單一連接的數(shù)據(jù)處理通常只需要零點(diǎn)幾秒的時間即可完成址遇，就算是最大只能使用 100 個連接也夠讓你用上很長一段時間。若是的 Server 有著非常高的最大連接數(shù)(max connections)或是單一連接需要很長時間才可完成斋竞，那么問題八成不是 maxconnections 的值不夠大而是在別的地方倔约，例如 slow queries、索引設(shè)計(jì)不良坝初、甚至是過于緩慢的 DNS 解析浸剩。在將 max_connections 的值調(diào)到 100 以上之前，應(yīng)該要先確定真的是因?yàn)镾erver 過于忙碌而需要調(diào)高此數(shù)值鳄袍，而不是其它地方出了問題绢要。每秒平均連接數(shù)有可能會很高，事實(shí)上拗小，若這個值很高而且 Server 的運(yùn)作十分順暢重罪，那么這通常會是一個好現(xiàn)象，無需擔(dān)心哀九。大部份 Server 的每秒平均連接數(shù)應(yīng)該都會低于 5/s剿配。

臨時表報表

或許看到一些explain查詢在分析時出現(xiàn)Using temporary的狀態(tài)，這意味著查詢過程中需要創(chuàng)建臨時表來存儲中間數(shù)據(jù)阅束，我們需要通過合理的索引來避免它惨篱。另一方面，當(dāng)臨時表在所難免時围俘，我們也要盡量減少臨時表本身的開銷砸讳，通過mysqlreport報告中的Created Temp部分琢融，我們可以看到：

MySQL可以將臨時表創(chuàng)建在磁盤（Disk table）、內(nèi)存（Table）以及臨時文件（File）中簿寂，顯然漾抬，在磁盤上創(chuàng)建臨時表的開銷最大，所以我們希望MySQL盡量不要在磁盤上創(chuàng)建臨時表常遂。 在MySQL的配置中纳令，我們可以通過tmptablesize選項(xiàng)來設(shè)置用于存儲臨時表的內(nèi)存空間大小，一旦這個空間不夠用克胳，MySQL將會啟用磁盤來保存臨時表平绩，你可以根據(jù)mysqlreport的統(tǒng)計(jì)盡量給臨時表設(shè)置較大的內(nèi)存空間。 在本示例中漠另，臨時表的情況如下捏雌，只用到了一個臨時表。

線程報表

MySQL采用多線程來處理并發(fā)的連接笆搓，通過mysqlreport中的Threads部分性湿，可以看到線程創(chuàng)建的統(tǒng)計(jì)結(jié)果：

也許你會覺得創(chuàng)建線程的消耗不值一提，但是所謂優(yōu)化都是在你系統(tǒng)繁忙下的救命稻草满败。 一個比較好的辦法是在應(yīng)用中盡量使用持久連接肤频，這將在一定程度上減少線程的重復(fù)創(chuàng)建。另一方面算墨，從上面的Cached=0可以看出宵荒，這些線程并沒有被復(fù)用。 在本例中净嘀，threadcachesize = 64报咳，只用到了5個線程，并且沒有復(fù)用（Cached)的面粮。

上面的%HIT需要關(guān)注下少孝，每一個連接到 MySQL 的聯(lián)機(jī)都是由不同的 Thread 來處理，當(dāng) MySQL 啟動時會預(yù)先建立一些 Threads 并保留在 Thread Cache 中熬苍，如此一來 MySQL 就不用一直忙著建立與刪除 Threads稍走。但當(dāng)每秒最大聯(lián)機(jī)數(shù)大于 MySQL 的 Thread Cache 時，MySQL 就會進(jìn)入Thread Thrash 的狀態(tài)：它不斷地建立新的 Threads 以滿足不斷增加的聯(lián)機(jī)的需求柴底。當(dāng) Thread Thrash 發(fā)生時婿脸，%Hit 的數(shù)值就會降低。在本范例中 %Hit 的值為 100%柄驻，這是非常好的狐树，因?yàn)樗硎編缀趺恳粋€新進(jìn)來的聯(lián)機(jī)都不會造成 MySQL 建立新的Thread。而在本例中鸿脓，threadcachesize是64抑钟，當(dāng)前Running的threads也很少涯曲，可見并沒有太大的壓力。

InnoDB緩存池報表

nnodbbufferpoolsize定義了InnoDB存儲引擎的表數(shù)據(jù)和索引數(shù)據(jù)的最大內(nèi)存緩沖區(qū)大小在塔。和 MyISAM 存儲引擎不同幻件， MyISAM 的 keybuffersize只能緩存索引鍵，而innodbbufferpoolsize卻可以緩存數(shù)據(jù)塊和索引鍵蛔溃。適當(dāng)?shù)脑黾舆@個參數(shù)的大小绰沥，可以有效的減少InnoDB類型的表的磁盤I/O。 如果你在MySQL中大量使用Innodb類型表贺待，則可以將緩沖池大小設(shè)置為物理內(nèi)存的60%-80%（最好配置成自增長的緩沖池）徽曲，并持續(xù)關(guān)注它的使用率。 如下Usage 表示, 總的緩存16G中, 當(dāng)前已占用2.27G, 使用率14.20%麸塞，這種情況下完全不用考慮增加innodb緩存池秃臣。 Read hit 表示緩存命中率 100%, 這個數(shù)值是比較理想的, 一般情況下, 都應(yīng)該大于 99.98%.

這部分?jǐn)?shù)據(jù)和innodbflushlogattrx_commit參數(shù)關(guān)系非常大。

innodbflushlogattrx_commit = 1 表示事務(wù)提交時立即將事務(wù)日志寫入磁盤喘垂，同時數(shù)據(jù)和索引也立即更新甜刻。這符合事務(wù)的持久性原則绍撞。

innodbflushlogattrx_commit = 0 表示事務(wù)提交時不立即將事務(wù)日志寫入磁盤正勒，而是每隔1秒寫入磁盤文件一次，并且刷新到磁盤傻铣，同時更新數(shù)據(jù)和索引章贞。這樣一來，如果mysqld崩潰非洲，那么在內(nèi)存中事務(wù)日志緩沖區(qū)最近1秒的數(shù)據(jù)將會丟失鸭限，這些更新將永遠(yuǎn)無法恢復(fù)。

innodbflushlogattrx_commit = 2 表示事務(wù)提交時立即寫入磁盤文件两踏，但是不立即刷新到磁盤败京，而是每隔1秒刷新到磁盤一次，同時更新數(shù)據(jù)和索引梦染。在這種情況下赡麦，即使mysqld崩潰后，位于內(nèi)核緩沖區(qū)的事務(wù)日志仍然不會丟失帕识，只有當(dāng)操作系統(tǒng)崩潰的時候才會丟失最后1秒的數(shù)據(jù)泛粹。

顯然，將innodbflushlogattrx_commit設(shè)置為0可以獲得最佳性能肮疗，同時它的數(shù)據(jù)丟失可能性也最大晶姊。

Free: 空閑頁，是使用率（%Used）的對立方伪货。 Data: 數(shù)據(jù)頁们衙，列%Dirty钾怔，展示已經(jīng)被修改過，但還沒有被刷新到磁盤存儲的數(shù)據(jù)頁的比率蒙挑。 Misc：用于管理分配行鎖和自適應(yīng)哈希索引導(dǎo)致的開銷使用的頁蒂教。 Latched: 目前正在讀寫、或者因?yàn)槠渌驘o法被刷新的頁脆荷。

Reads從內(nèi)存讀取的數(shù)量, 這個數(shù)值可以用來衡量innodb緩沖池的吞吐量,因?yàn)閹缀跛衖nondb需要的東西都是在緩沖池里凝垛，所以緩沖池的讀性能是越快越好。 哪怕超過每秒200000次也不是不可能的 From file: 從磁盤讀的數(shù)量蜓谋，越小越好梦皮。 Ahead Rnd: 隨機(jī)讀，innodb啟動的隨機(jī)讀取數(shù)桃焕。只有對表的大部分內(nèi)容進(jìn)行隨機(jī)掃描的時候才會出現(xiàn)剑肯。 Ahead Sql: 順序讀，只有全表掃描才會出現(xiàn)观堂。 Writes：本行顯示寫的數(shù)量以及讀寫的比率让网。如果服務(wù)器主要操作是update和insert的話，這個值也會比較高师痕。 Flushes: 緩沖池的頁刷新請求數(shù)溃睹。 Wait Free：一般情況下，innodb緩沖池的寫操作是后臺運(yùn)行的胰坟。不過因篇，如果出現(xiàn)必須要讀寫一個頁可偏偏沒有可用的新頁時，（innodb）就只能先等待頁的刷新了笔横。這個變量就是這些等待的總數(shù)竞滓。只要緩沖池的大小設(shè)置得當(dāng)，等待數(shù)應(yīng)該會很小吹缔。

innodb鎖報表

Waits：等待某行解鎖的累積次數(shù)商佑，最好為0。 Current：當(dāng)前正在等待解鎖的行個數(shù)厢塘，最好為0茶没。 Time acquiring：顯示了毫秒(ms)級行鎖等待數(shù)據(jù)。分別是總值俗冻、平均值和最大值礁叔。同樣最好是0次。

InnoDB數(shù)據(jù)迄薄、頁琅关、行報表

這部分報告，一般廣泛的用于衡量innodb引擎的吞吐量指標(biāo)。 Reads/Writes: 指的是整個innodb引擎完成所有的數(shù)據(jù)讀/寫次數(shù)涣易。注意：不是整個數(shù)據(jù)讀取字節(jié)數(shù)或者類型画机，而是innodb完成的數(shù)據(jù)讀/寫次數(shù)。 fsync： 刷新新症，innodb從內(nèi)存寫入磁盤的次數(shù)步氏。這個值應(yīng)該會比前兩個小。 Pending: 等待徒爹，又被分成了三行(108-110)荚醒，分別是讀、寫隆嗅、刷新的等待次數(shù)界阁。

包括三種自描述類型：創(chuàng)建、讀取胖喳、寫入泡躯，分別用來表示緩沖池中頁的創(chuàng)建、讀取 和寫入的數(shù)量和速率(即每秒操作數(shù))丽焊。

大家推薦一個學(xué)習(xí)資料分享群：747981058较剃，里面大牛已經(jīng)為我們整理好了許多的學(xué)習(xí)資料，有自動化技健，接口写穴，性能等等的學(xué)習(xí)資料！人生是一個逆水行舟的過程凫乖，不進(jìn)則退确垫，咱們一起加油吧弓颈！