下載地址

http://hackmysql.com/mysqlreport

用法

perl mysqlreport –user root –password –socket /tmp/mysql5-1.sock

Report Header: Line 1
報(bào)表的第一行包含了三樣不同的信息：
MySQL Server 的版本、自上次啟動(dòng)后已經(jīng)過(guò)多少時(shí)間、目前 Server 的日期與時(shí)間。有些人會(huì)定時(shí)讓系統(tǒng)自動(dòng)產(chǎn)生報(bào)表
(eg. cron)然后用程序去分析進(jìn)行分析，此時(shí)表頭將可用來(lái)協(xié)助您辨識(shí)出不同時(shí)間點(diǎn)的報(bào)表。對(duì)于那些租用或使用虛擬主機(jī)的管理者，表頭可以協(xié)助您了
解自己所需面對(duì)的是什么樣的 Server。MySQL Server 版本可以指出該 Server 有提供或沒(méi)有提供那些功能，而它的
Uptime 則表示該報(bào)表具有多大的代表性。Uptime 是重要的指標(biāo)，可讓您了解此份報(bào)表所包含的信息是否可能有偏誤，一般來(lái)說(shuō) Uptime
最少要有一小時(shí)會(huì)比較適當(dāng)，甚至光是一小時(shí)其實(shí)也還不夠。例如您的 Server 可能已執(zhí)行了六個(gè)小時(shí)，但此六小時(shí)皆是在使用率最低的午夜，此時(shí)產(chǎn)生出
的報(bào)表就很不具有代表性。最理想的情況下，你會(huì)希望 MySQL Server 至少已經(jīng)執(zhí)行了一整天，這樣子一來(lái)你就可以確定報(bào)表中的信息已包含了
Server 負(fù)載的高峰與低峰期，而不是只包含其中之一。在范例報(bào)表中 Server 只執(zhí)行了 34 分鐘，因此該報(bào)表的代表性是不足的，但因?yàn)檫@
只是用來(lái)做范例，也就沒(méi)什么關(guān)系。
Key Report: Lines 3 – 7
第一個(gè)主要報(bào)告
區(qū)塊就是 Key Report，因?yàn)?Key(Indexes, 索引)是所有信息中最重要的一項(xiàng)。雖然此報(bào)表無(wú)法告知您 Server 是否有善用
Index，但它可以告訴您 Server 對(duì)于 Shared Key Buffer 的使用狀態(tài)。請(qǐng)注意，這里所指的 Key Buffer 是指
MyISAM Storage Engine 所使用的 Shared Key Buffer，InnoDB 所使用的 Key Buffer 并不包
含在內(nèi)。
MySQL Server 支持許多種不同類型的數(shù)據(jù)表(比較正式的說(shuō)法是 Storage Engine)，你可以將它們想象為各種不
同的數(shù)據(jù)結(jié)構(gòu)，而不同的 Storage Engine 各有其優(yōu)缺點(diǎn)。其中 MySQL Server 預(yù)設(shè)是使用
MyISAM Storage Engine。
MySQL Server 的 Buffer 大略可分為二種：
1. Global Buffer：由所有 Client 所共享的 Buffer
key_buffer
innodb_buffer_pool
innodb_log_buffer
innodb_additional_mem_pool
net_buffer …等等

2. Thread Buffer：個(gè)別的 Connection 所需占用的 Buffer
例如：
sort_buffer
myisam_sort_buffer
read_buffer
join_buffer
read_rnd_buffer …等等

計(jì)算 Server 至少需使用的總內(nèi)存數(shù)量的方式為：
min_memory_needed = global_buffer + (thread_buffers * max_connection)
關(guān)于 MySQL 的 Cache 機(jī)制有一點(diǎn)需要特別注意，各位應(yīng)該都知道 MyISAM Storage Engine 將每個(gè) table 分成三個(gè)
檔案儲(chǔ)存在硬盤之中，例如若您有一個(gè)數(shù)據(jù)表的名稱為 example，那么您就會(huì)在硬盤上發(fā)現(xiàn) example.FRM, example.MYD,
example.MYI 等三個(gè)檔案。這三個(gè)檔案所儲(chǔ)存的數(shù)據(jù)如下：
FRM： 儲(chǔ)存這個(gè)數(shù)據(jù)表的結(jié)構(gòu)
MYD： Row Data，也就是你存在 example 數(shù)據(jù)表里的數(shù)據(jù)
MYI： 此數(shù)據(jù)表的索引接下來(lái)是重點(diǎn)：
當(dāng) MySQL 要 Cache 某個(gè)資料表時(shí)，請(qǐng)問(wèn) MySQL 會(huì) Cache 哪些資料？
答案是：
MySQL 只會(huì) Cache 索引，也就是 *.MYI 檔案，而 Row Data(*.MYD) 則是交由操作系統(tǒng)來(lái)負(fù)責(zé) Cache。
接下來(lái)我們?cè)倩氐?Key Buffer，有個(gè)很重要的問(wèn)題我們一直沒(méi)有回答，就是『到底 Key Buffer 要設(shè)定多少才夠呢？』。如前所述，
MySQL 只會(huì) Cache 索引(*.MYI)，因此您只要將數(shù)據(jù)庫(kù)中所有的 MYI 檔案加總起來(lái)，你就會(huì)知道大概要設(shè)為多少。
Buffer used: Line 4
身為 MySQL 的管理者您通常會(huì)問(wèn)的第一個(gè)問(wèn)題是：『Server 到底用掉了多少 key buffer？』。如果您發(fā)現(xiàn) MySQL 只使用了一小
部份的 Key Buffer，這并不是什么需要注意的問(wèn)題，因?yàn)?MySQL 只會(huì)在需要的時(shí)候才實(shí)際分配與使用 System RAM。也就是說(shuō)，當(dāng)
你設(shè)定 MySQL 可使用 512MB 的 RAM 時(shí)，并不代表 MySQL 啟動(dòng)的時(shí)候?qū)⒄加?512MB 的 RAM(只有在 MySQL 認(rèn)為
需要這么做的時(shí)候才會(huì))。報(bào)表中的第四行(Buffer used)指出 MySQL “曾經(jīng)” 耗用過(guò)的最大內(nèi)存數(shù)量，因此目前 “正在使用” 的內(nèi)存
數(shù)量有可能少于（甚至大于）這個(gè)數(shù)字。MySQL 稱此數(shù)值為 “High Water Mark”，但在報(bào)表的下一行我們將會(huì)看到它并不總是如此。無(wú)論
如何，從　Buffer used 我們通常可以看出 key_buffer_size 這個(gè)系統(tǒng)變量值是否設(shè)定的夠大，如果你的 MySQL 已經(jīng)使用
了 80~90% 以上的 Key Buffer，你就應(yīng)該要調(diào)高 key_buffer_size。注意，Buffer used 永遠(yuǎn)不會(huì)有使用率超
過(guò) 95% 的情況，因?yàn)?MySQL 的官方文件中指出 Share Key Buffer 中有部份將會(huì)挪用給內(nèi)部數(shù)據(jù)結(jié)構(gòu)使用，因此當(dāng)
Buffer used 指出 Share Key Buffer 的使用率高達(dá) 95% 時(shí)，其實(shí)在實(shí)務(wù)上等于是已使用了 100% 的
Share Key Buffer。在這個(gè)例子中 Server 只使用了 380KB(0.07%) 的 Share Key Buffer，看到這
里也許您會(huì)判斷 Server 的 Share Key Buffer 是十分充足的，但請(qǐng)勿太早下定論，我們必須要接著考慮報(bào)表中的下一行才能做出客觀
的判斷……。
Current: Line 5
mysqlreport 使用
Key_blocks_unused 這個(gè)系統(tǒng)變量來(lái)決定目前 MySQL “正在使用” 的 Share Key Buffer 大小，只有在
MySQL Server 4.1.2 以上的版本才會(huì)有這個(gè)功能。如果報(bào)表中的上一行(Buffer used)真的有如 MySQL 官方文件中所
說(shuō)的是 “High Water Mark”，那么 Current 所載明的數(shù)值應(yīng)該永遠(yuǎn)會(huì)小于或等于它。但在接下來(lái)的例子中我們將會(huì)看到，事情并不總
是如此。目前這臺(tái) Server 已經(jīng)使用了大約 60MB(12%) 的 Share Key Buffer，這是一個(gè)好現(xiàn)象因?yàn)樗砹四愕?br />Share Key Buffer 仍然十分充足。Current 與 Buffer used 合在一起看即可提供一個(gè)很有用的指標(biāo)，告訴您目前的
key_buffer_size 是否充足。
設(shè)定 key_buffer_size 的方式也很簡(jiǎn)單，只要直接修改 MySQL 的設(shè)定檔然后重新啟動(dòng) Server 即可。例如若要將 Key Buffer 設(shè)定為 2000MB，則只要在 /etc/my.cnf 中加上：
[mysqld]
key_buffer_size=2000M
Write ratio: Line 6
索
引(Indexes, Keys)主要是在內(nèi)存內(nèi)(RAM-Based)進(jìn)行操作的，索引之所以如此有用有部份原因就歸功于它們主要是在 RAM 里面運(yùn)
作，因此擁有極高的存取效能，不像儲(chǔ)存在硬盤中的數(shù)據(jù)存取速度非常慢。然而，不可否認(rèn)的是 MySQL 終究還是必須從硬盤中將索引讀入 RAM 或是將
儲(chǔ)存在 RAM 中的索引寫回硬盤之中。Write ratio 標(biāo)示著 MySQL 將索引寫入硬盤與 MySQL 將索引寫入 RAM 的比值
(Write Ratio = MySQL 將索引寫入硬盤的次數(shù) / MySQL 將索引寫入 RAM 的次數(shù))。具有接近于 1 的
Write Ratio 并不是一件很罕見(jiàn)的事，就像 MySQL 官方手冊(cè)中所說(shuō)的，如果你的 MySQL 最主要的活動(dòng)是 Update、
Insert 等等，那么 Write Ratio 將會(huì)很接近于 1。Write Ratio 若大于 1 表示 MySQL 將索引寫入硬盤的次數(shù)大
于將索引寫入 RAM 的次數(shù)，很少有 MySQL Server 的 Write Ratio 會(huì)大于 1，絕大部份都應(yīng)該會(huì)小于 1，即便是負(fù)載非常
重的 Server。
Read ratio: Line 7
Read Ratio 比
Write Ratio 來(lái)得重要一些，它標(biāo)示了 MySQL 從硬盤讀取索引與從 RAM 讀取索引的比值(Read Ratio = MySQL
從硬盤讀取索引的次數(shù) / MySQL 從 RAM 讀取索引的次數(shù))。Read Ratio 的值應(yīng)該要是 0.00 或 0.01，若大于這個(gè)值則表
示 Server 有問(wèn)題需要進(jìn)一步的調(diào)查，通常此問(wèn)題的成因是 Share Key Buffer 設(shè)得太小造成 MySQL 需要不斷地從硬盤中讀取
所需要的索引信息，而這個(gè)動(dòng)作是十分沒(méi)有效率的并且完全抵消了使用索引可以帶來(lái)的好處。在 Server 剛啟動(dòng)的頭一個(gè)小時(shí) Read Ratio 很
常會(huì)出現(xiàn)大于 0.01 的數(shù)值，但 Server 執(zhí)行過(guò)一陣子后它應(yīng)該(也必須)降低至 0.01 或是 0.00。
Questions Report: Lines 9 – 26
第
二個(gè)主要的報(bào)表區(qū)塊，Questions，是第二重要的信息，因?yàn)樗梢愿嬖V你 MySQL 到底都在忙些什么事情。Questions 包含了
SQL queries 以及 MySQL protocol communications。大部份的人都只在意 Server 每秒可以處理多少查
詢(Queries Per Second, QPS)，但若以整個(gè) Server 的觀點(diǎn)來(lái)考慮，QPS 其實(shí)是非常不精確的數(shù)值，它無(wú)法有效的告訴您
Server 的整體運(yùn)作狀況。而 Questions 則提供了較完整的信息，讓您一窺 Server 的全貌。
Total: Line 10
第
一個(gè)字段單純的記載 MySQL 總共響應(yīng)過(guò)多少查詢，第二個(gè)字段則記錄響應(yīng)的頻率(QPS)，當(dāng)大部份的人說(shuō)『我的 Server 平均每秒處理
XXX 個(gè)查詢』時(shí)，他們指的其實(shí)就是第二個(gè)字段所記錄的響應(yīng)頻率。此時(shí)你應(yīng)該要反問(wèn)他們『在那 XXX 個(gè)查詢之中，MySQL 到底做了哪些事
情？』，接下來(lái) mysqlreport 將可以協(xié)助您回答此問(wèn)題……。
Distribution of Total Queries (DTQ): Lines 11 – 15
所有的 Questions 可以大致區(qū)分為五個(gè)不同的類別：
1.Data Manipulation Statements (DMS)
2.query cache hits (QC Hits)
3.COM_QUIT
4.all other Com_ commands
5.Unknown
這
五個(gè)類別將會(huì)展示在 Lines 11 至 15，但它們的順序是會(huì)改變的。mysqlreport 預(yù)設(shè)是以查詢的總數(shù)(第一個(gè)字段)來(lái)排序，次數(shù)越多
排得越上面，讓您可以快速的分辨出 MySQL 大部份時(shí)間都在忙些什么東西。理想的情況下，你會(huì)希望 MySQL 把大部份的時(shí)間都花在 DMS 與
QC Hits 這兩個(gè)類別，因?yàn)檫@兩個(gè)類別才是真正在 “完成正事” 的類別。COM_QUIT、Com_、與 Unknown 也有其存在的必要，
但它們應(yīng)該只占了其中的一小部份。在繼續(xù)深入介紹之前，也許你會(huì)好奇第三個(gè)字段是做什么用的，它代表了該分類(例如 DMS)占全部 Queries 的
百分比；若是在子分類(例如 Select)中，則表示該子分類占所屬分類(例如 DMS)的百分比。在此范例中 DMS 占了所有 Queries 的
82.84%，這是一個(gè)很好的現(xiàn)象。
Data manipulation statements(DMS) 包
含了：ELECT, INSERT, REPLACE, UPDATE, 與 DELETE(技術(shù)上來(lái)說(shuō)，其實(shí)不只這幾個(gè)類別但
mysqlreport 只會(huì)用到這幾類)。基本上，你可以將 DMS 想成是 MySQL 真正有在做些 “有用的事” 的情況，因此你會(huì)希望
DMS 是 MySQL 最忙著處理的事情。
QC Hits
是 MySQL 不需要實(shí)際執(zhí)行 Query 而只要直接從 Query Cache 中即可找到所需數(shù)據(jù)的次數(shù)。擁有高比例的 QC Hits 是讓人
夢(mèng)寐以求的事，因?yàn)閺?Query Cache 直接存取所需要的數(shù)據(jù)是十分快速且有效率的。然而大部份的 MySQL Server 因?yàn)楦鞣N原因，而
無(wú)法具有非常有效率的 Query Cache。在本范例中 QC Hits 占了所有 Questions 的 16.91%，這是非常好的情況。然
而，千萬(wàn)不要被這個(gè)數(shù)值給誤導(dǎo)了，在報(bào)表中的 38 至 45 行(Query Cache Report)將會(huì)告訴您完全不同的狀況。這是一個(gè)很好的范
例，展示了 mysqlreport 可以做為深入、相互參照與比對(duì)的分析工具。當(dāng) QC Hits 看來(lái)似乎十分完美時(shí)，這個(gè) Server 的
Qeury Cache Report 卻可以明確的告訴您其實(shí)事情沒(méi)有表面上看起來(lái)的那樣完美，我們?cè)谏院髸?huì)在回到這個(gè)問(wèn)題。
COM_QUIT 算是比較不重要的類別，若您不是真的很有興趣其實(shí)您大可忽略這個(gè)類別的內(nèi)容。
COM_ 這
個(gè)類別代表著所有 MySQL 所執(zhí)行過(guò)的指令，通常與 MySQL protocol 相關(guān)。在正常的情況下，你會(huì)希望這個(gè)類別所占的比例越低越好，因
為當(dāng)這個(gè)數(shù)值很高的時(shí)候就表示 MySQL 正忙碌于無(wú)關(guān)緊要的事情上。若這個(gè)數(shù)值很高通常代表 MySQL 正遭遇到某些很奇怪的問(wèn)題，當(dāng)我們深入討論
COM_ 的子類別的時(shí)候，我們會(huì)在回來(lái)探討這個(gè)問(wèn)題。
Unknown 是
推論出來(lái)的類別，在理想的狀況下，之前所述的四個(gè)分類加總起來(lái)應(yīng)該要等于 Questions 總數(shù)，但它們通常不會(huì)剛好等于。這是因?yàn)橛行?br />Questions MySQL 在處理時(shí)會(huì)增加 Total Questions 的計(jì)數(shù)器，但卻沒(méi)有相對(duì)應(yīng)的系統(tǒng)變量用來(lái)記錄所執(zhí)行過(guò)的
Questions。在不同的 Server 上這個(gè)數(shù)值的變異很大，在有些 Server 上這個(gè)數(shù)值非常的高，在有些 Server 上則非常的
低，但在大部份的情況下它應(yīng)該要維持在很低的水平才是。如果這個(gè)數(shù)值非常的高，可能代表 MySQL Server 有什么地方出了問(wèn)題。
Slow: Line 16
第 16
行非常的重要：它記錄了 MySQL 總共執(zhí)行了多少次 Slow Query。Slow Query 就是指執(zhí)行所需時(shí)間超過(guò)某個(gè)時(shí)間區(qū)間的
Query，例如執(zhí)行超過(guò) 10 秒的 Query。用來(lái)判定是否為 Slow Query 的時(shí)間區(qū)間是可以透過(guò) long_query_time
這個(gè)系統(tǒng)變量來(lái)設(shè)定的，MySQL 預(yù)設(shè) long_query_time 為 10 秒，但通常我們會(huì)將它設(shè)定為 5 秒。在最理想的情況下，我們會(huì)希
望看到這個(gè)數(shù)值等于零，但通常這數(shù)值不會(huì)是零。一般來(lái)說(shuō) Slow Query 占 Total Questions 的比例應(yīng)該要低于 0.05，
Slow Query 的次數(shù)(第一個(gè)字段)本身不是很重要，真正需要注意的是 Slow Query 占 Total Questions 的比例，若
這比例偏高就代表 Server 有些問(wèn)題需要解決。第四個(gè)字段中的『%DMS: 』表示 Slow Query 在所有 DMS 中所占的比例。
DMS: Lines 17 – 22
DMS
的子分類項(xiàng)目可以告訴我們，這臺(tái) MySQL Server 是屬于哪一個(gè)類型的 MySQL Server，例如它是著重在 SELECT 操作或是
INSERT 操作，大部份的 MySQL Server 都是著重在 SELECT 操作。知道某臺(tái) Server 是屬于哪一個(gè)類型的
MySQL Server 有助于我們思考報(bào)表中的其它信息，例如一臺(tái)著重在 SELECT 操作的 MySQL Server 的
Write Ratio 應(yīng)該會(huì)非常的接近 1，并有著較高的 Lock 時(shí)間。同時(shí)它也隱含了一個(gè)意義，就是也許你可以考慮使用
InnoDB Storage Engine，因?yàn)?MySQL 預(yù)設(shè)采用的 MyISAM Storage Engine 所提供的 Lock 層級(jí)
只有 Table Lock(只能針對(duì)整個(gè)數(shù)據(jù)表鎖定)，而 InnoDB 則提供 Row Lock 層級(jí)的鎖定機(jī)制(可只針對(duì)特定的 ROW 進(jìn)行鎖
定，減少等待時(shí)間)。若是著重在 SELECT 操作的 Server，它的 Read Ratio 應(yīng)該會(huì)接近于零，并有著非常低的
Table Lock 時(shí)間。
在范例中的 Server 是屬于著重在 SELECT 操作的 Server：65.72% 的
Questions 是 SELECT(第三個(gè)字段)、79.33% 的 DMS Questions 是 SELECT(第四個(gè)字段)。很明顯的，這
是臺(tái)著重在 SELECT 操作的 Server，知道了此項(xiàng)事實(shí)之后，我們才有辦法對(duì)其進(jìn)行最佳化。
Com_: Lines 23 – 26
這個(gè)子分類只有在它的值偏高的時(shí)候才需要注意，因?yàn)檫^(guò)高的值表示 MySQL 正在忙著處理 “程序方面的東西”，而不是響應(yīng)使用者的查詢。對(duì)大部份的 Server 來(lái)說(shuō)這里應(yīng)該都不會(huì)出現(xiàn)偏高的數(shù)值，但您最好還是定期的檢查一下。
SELECT and Sort Report: Lines 28 – 36
大
致上來(lái)說(shuō)，你只要注意第 29 行與第 31 行：Scan 與 Full Join。Scan 指的是有多少 SELECT statements 造
成 MySQL 需要進(jìn)行 Full Table Scan。Full Join 的意思與 Scan 差不多，但它是適用在多個(gè) Tables 相互
Join 在一起的情況。這二種情況的執(zhí)行效能都非常的差，因此原則上你會(huì)希望這兩個(gè)數(shù)值越低越好。但這也不是絕對(duì)的，仍然要考慮實(shí)際的情況，例如雖然
Server 有很高比例的 Scan，但若這些 Scan 都是針對(duì)一些只有幾十筆數(shù)據(jù)的 table，那么相對(duì)而言它依然是十分有效率的；但反之，
若這些 Scan 是針對(duì)具有上百萬(wàn)筆數(shù)據(jù)的 table，那么就會(huì)嚴(yán)重影響系統(tǒng)效能。
Query Cache Report: Lines 38 – 45
Query Cache Report 只有在 MySQL 有支持 Query Cache，以及 Query Cache 功能有開(kāi)啟的情況下才會(huì)有這段信息出現(xiàn)。
Memory usage: Line 39
此項(xiàng)目指出 Query Cache 的使用狀況，若系統(tǒng)已達(dá)到 Query Cache 的上限則會(huì)連帶影響到 Prunes Value，因?yàn)楫?dāng)配給的 Memory 不足時(shí)，MySQL 必須不斷地消除 RAM 中較不常使用的數(shù)據(jù)以挪出空間擺放新的數(shù)據(jù)。
Block Fragmnt: Line 40
這
個(gè)數(shù)值越高表示 Query Cache 的 Fragment 狀況越嚴(yán)重，通常它會(huì)界于 10%~20% 之間。在此范例中
Block Fragmnt 為 13.05%，這是可接受的情況，當(dāng)然你也可以調(diào)整 query_cache_min_res_unit 的值來(lái)降低
Block Fragmnt。
Hits, Inserts, Prunes: Lines 41 – 43
Hits
是這三個(gè)數(shù)值中最重要的一項(xiàng)，因?yàn)樗赋鲇卸嗌?SELECT statements 是可直接從 Query Cache 里面取得所需的信息，此數(shù)值
越高就越好。Inserts 和 Prunes 最好是從第 44 行的比值來(lái)觀察比較容易理解。雖然 Prunes 的值偏高可能代表著
Query Cache 設(shè)得不夠大，但并不一定是如此。在本例中只有 55% 的 Query Cache 被使用，有著相對(duì)而言算低的
fragmentation 值，但 Prunes 值偏高，Prunes 的值(16/s)是 QC Hits 的兩倍。你可以想象這臺(tái)
Server 的 Query Cache 是一顆蘋果樹，它的樹枝被剪去的速度比你采收蘋果的速度還快。
Insrt:Prune and Hit:Insert Ratios: Lines 44 – 45
第 44
行中的 Insert 與 Prune 的比值可顯示 Query Cache 的揮發(fā)性。在一個(gè)高度穩(wěn)定的 Query Cache 中，Insrt
的值應(yīng)該要高于 Prune 的值；反之，在一個(gè)揮發(fā)性較高(較不穩(wěn)定)的 Query Cache 中，這個(gè)比值將會(huì)是 1:1 或是偏重在
Prune 那方，這表示 Query Cache 中的數(shù)據(jù)有可能在使用到之前就已經(jīng)被清除了。我們會(huì)希望擁有一個(gè)穩(wěn)定的 Query Cache，
因?yàn)榉€(wěn)定的 Query Cache 表示那些被 Cache 在 Query Cache 中的資料會(huì)常被用到。高揮發(fā)性(較不穩(wěn)定)的
Query Cache 代表兩件事情：第一，Query Cache 設(shè)得太小，需要加大。第二，MySQL 正試圖要 cache 所有的東西，甚
至是那些其實(shí)并不需要 cache 的數(shù)據(jù)。若是第一種狀況，只要單純的加大 Query Cache 即可。若是第二種情況，可能是 MySQL 試圖
要去 cache 所有可以 cache 的數(shù)據(jù)，你可以使用 SQL_NO_CACHE 來(lái)明確的告訴 MySQL 什么資料是你不想要 cache
的。
Hit 與 Insert 的比值代表著 Query Cache 的有效性，理想的情況是我們新增了一些 Qeury 到
Query Cache 中，然后希望得到許多 Hits。因此若是這個(gè) Query Cache 是有效率的，那么該比值應(yīng)該要偏重在左方。若比值是
偏重在 Insert 那方，那么這個(gè) Query Cache 的揮發(fā)性就太高了。考慮以下這個(gè)比值，若 Hit:Insert 為 1:1，那就表示
Query Cache 中的數(shù)據(jù)只使用了一次就被清除掉了，換句話說(shuō)，我們放進(jìn)去的數(shù)據(jù)比我們從里面拿出來(lái)的數(shù)據(jù)還多，這樣一來(lái)就失去了使用
Query Cache 的意義。回想我們前面所提過(guò)的，雖然在本范例中 QC Hit 在全部的 Questions 中占了很高的比例，但實(shí)際上我
們可以發(fā)現(xiàn) QC 的有效性其實(shí)是很低的(Hit:Insert 的比值偏重在 Insert 那方)。若造成這個(gè)現(xiàn)象的原因是 MySQL 正試圖
cache 所有的東西，那么將 Cache 模式改為 DEMAND 或許可以解決此問(wèn)題。
Table Locks Report: Lines 47 – 49
這
個(gè)部份包含了兩項(xiàng)信息：第一項(xiàng)是 Waited，代表 MySQL 需要等待以取得 table lock 的次數(shù)。第二項(xiàng)是 Immediate，表示
MySQL 不需要等待即可立刻取得 table lock 的次數(shù)。對(duì)數(shù)據(jù)庫(kù)來(lái)說(shuō)『等待』幾乎可以肯定是一件很不好的事情，因此 Waited 的值
應(yīng)該要越小越好。最具有代表性的是第三個(gè)字段(Waited 占所有 table lock 的百分比)，這個(gè)數(shù)值應(yīng)該要小于 10%，大于這個(gè)值就表示
table/query 的索引設(shè)計(jì)不良或是有過(guò)多的 Slow Query。
Tables Report: Lines 51 – 53
Tables Report
同樣包含了二項(xiàng)信息：第一是 Open，顯示目前正開(kāi)啟的 table 數(shù)量、總共可開(kāi)啟的最大數(shù)量，以及 Table Cache 的使用狀況。第二是
Opend，表示截至目前為止 MySQL 總共開(kāi)啟過(guò)的 Table 數(shù)量，以及除上 Uptime 后的比值。這里有兩件事值得注意：首先是
Table Cache 的使用狀況，100% 的 Table Cache 使用率并不是一件壞事但你可以試著調(diào)大 Table Cache 以增進(jìn)
效能。第二是 MySQL 開(kāi)啟 Table 的平均速率，若這個(gè)值很高則表示您的 table_cache 設(shè)得太小了，需要調(diào)大一些。一般來(lái)說(shuō)，
MySQL 開(kāi)啟 Table 的平均速率最好是小于 1/s。但大于這個(gè)數(shù)值也不一定就是壞事，有些調(diào)校良好且運(yùn)作的十分有效率的
MySQL Server 其值為 7/s 并使用了 100% 的 Table Cache。
Connections Report: Lines 55 – 57
Connections Report
所代表的意義與 Tables Report 相似，請(qǐng)各位以此類推。比較需要注意的是：若你發(fā)現(xiàn) Connections 的使用率接近 100%，也
許你會(huì)想調(diào)大 max_connections 的值以允許 MySQL 的 Client 建立更多聯(lián)機(jī)。然而，這通常是一種錯(cuò)誤。我們常常可以發(fā)現(xiàn)很
多網(wǎng)絡(luò)上的數(shù)據(jù)會(huì)教我們要調(diào)大 max_connections，但卻從來(lái)沒(méi)有給一個(gè)明確的理由。事實(shí)上，max_connections 的默認(rèn)值
(100)，就算是對(duì)于負(fù)載十分沉重但有良好調(diào)校過(guò)的 Server 都已十分足夠。MySQL 對(duì)于單一聯(lián)機(jī)的數(shù)據(jù)處理通常只需要零點(diǎn)幾秒的時(shí)間即可完
成，就算是最大只能使用 100 個(gè)聯(lián)機(jī)也夠讓你用上很長(zhǎng)一段時(shí)間。若是您的 Server 有著非常高的最大聯(lián)機(jī)數(shù)(max connections)
或是單一聯(lián)機(jī)需要很長(zhǎng)時(shí)間才可完成，那么問(wèn)題八成不是 max_connections 的值不夠大而是在別的地方，例如 slow queries、索
引設(shè)計(jì)不良、甚至是過(guò)于緩慢的 DNS 解析。在您將 max_connections 的值調(diào)到 100 以上之前，您應(yīng)該要先確定真的是因?yàn)?br />Server 過(guò)于忙碌而需要調(diào)高此數(shù)值，而不是其它地方出了問(wèn)題。每秒平均聯(lián)機(jī)數(shù)有可能會(huì)很高，事實(shí)上，若這個(gè)值很高而且 Server 的運(yùn)作十分
順暢，那么這通常會(huì)是一個(gè)好現(xiàn)象，無(wú)需擔(dān)心。大部份 Server 的每秒平均聯(lián)機(jī)數(shù)應(yīng)該都會(huì)低于 5/s。
Created Temp Report: Lines 59 – 62
MySQL
可以建立暫時(shí)性的數(shù)據(jù)表，它可建立在硬盤中、檔案里、或是 RAM 之中，而 Created Temp Report 則提供了相關(guān)的數(shù)據(jù)供您參考。這
些數(shù)據(jù)大多是相對(duì)而言，沒(méi)有一定的標(biāo)準(zhǔn)，但將暫時(shí)性的數(shù)據(jù)表建立在硬盤中是十分沒(méi)有效率的，因此 Disk table 的值最好是三者中最小的一個(gè)。當(dāng)
暫時(shí)性的數(shù)據(jù)表被建立在硬盤中，表示此數(shù)據(jù)表沒(méi)有辦法被放進(jìn) RAM 里面（因?yàn)?tmp_table_size 的值設(shè)得不夠大）。
Threads, Aborted, Bytes Reports: Lines 64 – 76
這
幾個(gè)部份大多沒(méi)什么好解釋的，只有一個(gè)項(xiàng)目值得特別說(shuō)明：第 66 行的最后一個(gè)字段(%Hit)。每一個(gè)連接到 MySQL 的聯(lián)機(jī)都是由不同的
Thread 來(lái)處理，當(dāng) MySQL 啟動(dòng)時(shí)會(huì)預(yù)先建立一些 Threads 并保留在 Thread Cache 中，如此一來(lái) MySQL 就不
用一直忙著建立與刪除 Threads。但當(dāng)每秒最大聯(lián)機(jī)數(shù)大于 MySQL 的 Thread Cache 時(shí)，MySQL 就會(huì)進(jìn)入
Thread Thrash 的狀態(tài)：它不斷地建立新的 Threads 以滿足不斷增加的聯(lián)機(jī)的需求。當(dāng) Thread Thrash 發(fā)生時(shí)，%
Hit 的數(shù)值就會(huì)降低。在本范例中 %Hit 的值為 0.05%，這是非常不好的，因?yàn)樗硎編缀趺恳粋€(gè)新進(jìn)來(lái)的聯(lián)機(jī)都會(huì)造成 MySQL 建立新的
Thread。我們可以看到在此范例中造成此現(xiàn)象的原兇就在第 66 行的第一個(gè)字段，我們可以發(fā)現(xiàn) Thread Cache 的值為 0，因此
thread_cache_size 的值需要調(diào)大。
話說(shuō)回來(lái)，究竟 %Hit 接近于零真的有什么關(guān)系嗎？Jeremy Zawondy 曾
在部落格上說(shuō)到：Thread caching 并不是我們最需要關(guān)心的問(wèn)題，但當(dāng)你解決了所有其它更嚴(yán)重的問(wèn)題之后，它就會(huì)是最嚴(yán)重的問(wèn)題

轉(zhuǎn)載于:https://blog.51cto.com/shanks/1307634

總結(jié)

以上是生活随笔為你收集整理的mysqlreport查看mysql性能的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。