MySQL 效能監控工具--mysqlreport
hackmysql.com 的站長所撰寫的 Perl Scritps，旨在協助 MySQL DBA 蒐集與分析 MySQL 的運作狀況。
官方網站：
軟體下載：
命令列選項的格式是 --選項，不過 -選項 的格式也可以。所有的選項都有其縮寫，只要是唯一的。例如，選項 --host 可以縮寫成 --ho，不過不能寫成 --h，因為 --h 有歧義，可能是 --host 或者 --help。
選項列表
--user USER
--password
--host ADDRESS
--port PORT
--socket SOCKET
--no-mycnf
--help
這些選項是模擬其他標準應用程式的。從 2.3 版本開始，--password 可以在後面加上引數，如 "--password
FOO"。如果命令列中只指定了選項 --password，則會提示輸入密碼。--no-mycnf 告訴 mysqlreport 不要讀取
~/.my.cnf，預設會去讀取這個檔案。--user 和 --password 總是覆蓋從 ~/.my.cnf 中取得的結果。
--infile FILE
直接從檔案中讀取狀態檔案，而不是從MySQL的 SHOW STATUS 中讀取。檔案內容通常是從 SHOW STATUS
的結果中取得，並且包含格式化字元(|, +, -)。mysqlreport 認為這樣的檔案"狀態名 數值"格式的，狀態包含字元和下劃線(A-Z
和 _)，數值則是非負整數。在狀態名和數值之間的任何內容都會被忽略。mysqlreport 也需要以下
MySQL伺服器系統變數
：version,
table_cache, max_connections, key_buffer_size, query_cache_size,
thread_cache_size。INFILE 的格式也可以是 "名字 =
數值"這樣的，名字可以使是上面提到的各種變數名，數值是非負整數，可能後面帶有M或者其他單位(根據版本不同而定)。例如，想要指定 18M 的
key_buffer_size：key_buffer_size = 18M。或者，256 個 table_cache：table_cache
= 256。M 指兆位元組，而非百萬。因此 18M 是 18,874,368，而非
18,000,000。如果這些伺服器變數沒有指定，則使用預設以下預設值：0.0.0, 64, 100, 8M, 0,
0，就可能會讓報告結果看起來很奇怪。
注意：MySQL 伺服器版本在 5.1.3 或更新時，儘管系統變數 table_cache 改成了 table_open_cache，但是讀取本地檔案時仍採用 table_cache。
--outfile FILE
在螢幕顯示完報告結果後，將結果寫入檔案中。mysqlreport
的內部機制總是先將結果寫入臨時檔案中。然後將該臨時檔案裡的內容列印到螢幕上。然後，如果指定了 --outfile 選項，則將臨時檔案複製成
OUTFILE。如果指定選項 --email，則會刪除臨時檔案。
--email ADDRESS
在螢幕顯示完結果後，將結果傳送到郵件地址 ADDRESS 中去。欲該選項，需要在 /usr/sbin/ 目錄下有 sendmail
程式，因此無法在 windows 平臺下使用。/usr/sbin/sendmail 可以符號連結到 qmail，或者任何其他能模擬
sendmail -t 方式的 MTA 程式。郵件來源是：mysqlreport，主題是：MySQL status report on
HOST，HOST 是 mysqlreport
所在的主機名，可能是讀取到的 --host 值，預設是 localhost。
--flush-status
顯示完報告後，執行 "FLUSH STATUS;" 語句。如果沒有許可權，則 DBD::mysql 會顯示返回值。
--relative (-r) X
mysqlreport 通常情況下報告的是自從 MySQL 伺服器啟動以來的狀態資訊。--relative 選項則是令 mysqlreport 產生一份自從上次報告以來的相關報告。
如
果 --relative X 的 X 值是一個整數，則 mysqlreport 會在隔 X 秒後再次產生一份 MySQL
伺服器的狀態報告。產生報告的次數是由 --report-count 選項來控制的。預設是產生 1 份相關的報告。例如，指定
--relative 的值為 60，則會產生 2 份報告：第一份會馬上生成，第二份會在 60
秒後再次生成。第二份報告中的數值會和前面的那份相關。例如，前面那份中總共有 10.00k 次查詢，在這 60 秒的間隔時間裡接受了新的
1.00k 次查詢，則第二份的報告中的總查詢次數是 1.00k 而非 11.00k 次。
如果
--relative 選項的值也可以是本地檔案(類似 --infile 選項的用法)，那麼 mysqlreport
會按照引數值中檔案的順序來依次產生狀態報告。因此，根據這些檔案產生的時間來指定選項的值非常重要：較早產生的檔案放在引數的前面。第一個檔案中必須有
手工新增的系統變數，例如：key_buffer_size、table_cache 等。每個檔案中可以有多組 "SHOW STATUS"
的結果。注意：透過 "mysqladmin -r -i N extended" 產生的狀態檔案無法使用，因為 mysqladmin 的 -r
引數已經令其產生了具有相對性的狀態值了。
由於 mysqlreport 首先會把狀態報告寫到臨時檔案中，如果 --relative 的值是 整數(而非 本地檔案)時，mysqlreport 會顯示它把檔案寫到哪了。那麼就可以直接透過檢視這些檔案內容來觀察伺服器的狀況了。
--report-count (-c) N
生成 N 份相關的報告。本選項只有在同時啟用 --relative 選項後才有效。mysqlreport 會自動產生 N+1 份報告：第一份基本報告，以及後面的 N 份相關報告。
--detach
若指定本選項，則 mysqlreport
會派生出程式來，不只是在螢幕顯示結果，還會轉入後臺繼續執行。派生新程式後，mysqlreport
會報告它把結果寫入哪個臨時檔案了。本選項還可以指定 --outfile 或 --email 的一個。如果沒有指定 --outfile 或
--email 的值，則產生的臨時檔案會被刪除，因為 mysqlreport 派生出新程式後，無法再將結果列印到終端螢幕上了。本選項如果和
--relative 一起使用的話就更有意義了，這樣 mysqlreport
就能定時報告資訊，而無需人工登入等方式在中斷執行了。使用如下的命令，就能讓 mysqlrepot
隔一個小時再次產生一次報告，並將結果傳送到自己的信箱中去：
mysqlreport -r 3600 -detach -email host@domain.com
一個小時候後，mysqlreport 透過email傳送報告，刪除臨時檔案，並且乾淨地終止。
--debug
顯示除錯資訊。
--dtq
(Questions 報告的 Total 部分中)顯示所有的查詢分佈報告。這些查詢主要包括以下四部分：DMS (見下面)、COM_ (見下面)、COM_QUIT(見
)、以及其他未知。每部分根據其總數倒序顯示。
--dms
(Questions 報告的 DMS 部分中)顯示所有的資料維護語句(DMS)報告。DMS是下面文件
13.2. Data Manipulation Statements
中提到的那些(當前主要有：SELECT, INSERT, REPLACE, UPDATE, and DELETE)。每個 DMS 根據其總數倒序顯示。
--com N
(Questions 報告之後)以降序顯示最多 N 個 非DMS Com_ 狀態值。如果沒有指定 N 的值，則預設是 3。所謂的非DMS Com_ 狀態值，包括：Com_change_db、Com_show_tables、Com_rollback 等。
--sas
(Questions 報告之後)，顯示所有的 Select_ 和 Sort_ 報告。詳情請看
。
--qcache
如果開啟查詢快取的話，則顯示查詢快取狀態報告。
--tab
(Create Temp 報告之後)顯示 執行緒、放棄的、流量 等狀態報告。從 mysqlreport v2.3 開始，執行緒狀態是從 Threads_ 狀態值讀取。
--innodb
顯示
InnoDB
狀態報告，包括MySQL 5.0.2以後才支援的InnoDB 緩衝池，以及5.0.3以後才支援的InnoDB鎖狀態報告。
--innodb-only
只顯示 InnoDB 報告；不顯示其他報告。
--dpr
顯示 InnoDB 資料，頁，行報告。
--all
如果可能，則顯示所有的狀態報告。一些報告，比如查詢快取、InnoDB等需要特定版本的MySQL或者其他特性才能支援。例如，儘管伺服器支援查詢快取，但是它被禁用了，則不管是否指定了 --qcache 或者 --all，都不會顯示查詢快取的報告。
mysqlreport
可將重要的 MySQL 系統資訊整理為具有較高可讀性的報表，使你更容易閱讀與深入理解目前 MySQL 的實際運作狀況。除了手動執行
SHOW STATUS 指令並以人眼去過濾與判斷目前的系統狀態以外，mysqlreport 大概是較好(八成也是唯一)的替代方案。
目前
的 mysqlreport 版本可以產生大量、具有完善資訊的報表，其報表完整的覆蓋了實務上所有重要的 MySQL 系統資訊，也可以產生只具有最重
要資訊的較精簡報表。完整的報表包含了 14 種不同面向，超過 121 行的完整資訊；精簡的報表包含了 6 種不同面向，總計 29 行的最重要信
息。
此檔案可教導您如何解讀 mysqlreport 所產生出來的各項資訊。如此一來，當您在閱讀 mysqlreport 所產生出來的報表時，您才可以回答最重要的問題：『MySQL Server 目前的運作狀況究竟如何？』
為了讓您有較深入的理解，此檔案將從報表的第一行開始逐項的解釋，當您閱讀完此檔案後，您應該具有完整的知識可以將 mysqlreport 佈署在任何 Server 上，並且有效的掌握 MySQL Server 的運作實況。
在開始之前，這裡有一份範例報表，我們將以此份報表為藍本開始進行教學。
（建議您將此報表列印出來和內文對照看，這樣子會比較容易理解文章內容）
PHP 語法:
1 MySQL 5.0.3 uptime 0 0:34:26 Fri Sep 1 19:46:02 2006
2
3 __ Key _________________________________________________________________
4 Buffer used 380.00k of 512.00M %Used: 0.07
5 Current 59.32M %Usage: 11.59
6 Write ratio 0.93
7 Read ratio 0.00
8
9 __ Questions ___________________________________________________________
10 Total 98.06k 47.46/s
11 DMS 81.23k 39.32/s %Total: 82.84
12 QC Hits 16.58k 8.02/s 16.91
13 COM_QUIT 200 0.10/s 0.20
14 Com_ 131 0.06/s 0.13
15 -Unknown 82 0.04/s 0.08
16 Slow 0 0.00/s 0.00 %DMS: 0.00
17 DMS 81.23k 39.32/s 82.84
18 SELECT 64.44k 31.19/s 65.72 79.33
19 INSERT 16.75k 8.11/s 17.08 20.61
20 UPDATE 41 0.02/s 0.04 0.05
21 REPLACE 0 0.00/s 0.00 0.00
22 DELETE 0 0.00/s 0.00 0.00
23 Com_ 131 0.06/s 0.13
24 change_db 119 0.06/s 0.12
25 show_fields 9 0.00/s 0.01
26 show_status 2 0.00/s 0.00
27
28 __ SELECT and Sort _____________________________________________________
29 Scan 38 0.02/s %SELECT: 0.06
30 Range 14 0.01/s 0.02
31 Full join 3 0.00/s 0.00
32 Range check 0 0.00/s 0.00
33 Full rng join 0 0.00/s 0.00
34 Sort scan 14 0.01/s
35 Sort range 26 0.01/s
36 Sort mrg pass 0 0.00/s
37
38 __ Query Cache _________________________________________________________
39 Memory usage 17.81M of 32.00M %Used: 55.66
40 Block Fragmnt 13.05%
41 Hits 16.58k 8.02/s
42 Inserts 48.50k 23.48/s
43 Prunes 33.46k 16.20/s
44 Insrt:Prune 1.45:1 7.28/s
45 Hit:Insert 0.34:1
46
47 __ Table Locks _________________________________________________________
48 Waited 1.01k 0.49/s %Total: 1.24
49 Immediate 80.04k 38.74/s
50
51 __ Tables ______________________________________________________________
52 Open 107 of 1024 %Cache: 10.45
53 Opened 118 0.06/s
54
55 __ Connections _________________________________________________________
56 Max used 77 of 600 %Max: 12.83
57 Total 202 0.10/s
58
59 __ Created Temp ________________________________________________________
60 Disk table 10 0.00/s
61 Table 26 0.01/s
62 File 3 0.00/s
63
64 __ Threads _____________________________________________________________
65 Running 55 of 77
66 Cache 0 %Hit: 0.5
67 Created 201 0.10/s
68 Slow 0 0.00/s
69
70 __ Aborted _____________________________________________________________
71 Clients 0 0.00/s
72 Connects 8 0.00/s
73
74 __ Bytes _______________________________________________________________
75 Sent 38.46M 18.62k/s
76 Received 7.98M 3.86k/s
Report Header: Line 1
報表的第一行包含了三樣不同的資訊：
MySQL Server 的版本、自上次啟動後已經過多少時間、目前 Server 的日期與時間。有些人會定時讓系統自動產生報表
(eg. cron)然後用程式去分析進行分析，此時表頭將可用來協助您辨識出不同時間點的報表。對於那些租用或使用虛擬主機的管理者，表頭可以協助您了
解自己所需面對的是什麼樣的 Server。MySQL Server 版本可以指出該 Server 有提供或沒有提供那些功能，而它的
Uptime 則表示該報表具有多大的代表性。Uptime 是重要的指標，可讓您瞭解此份報表所包含的資訊是否可能有偏誤，一般來說 Uptime
最少要有一小時會比較適當，甚至光是一小時其實也還不夠。例如您的 Server 可能已執行了六個小時，但此六小時皆是在使用率最低的午夜，此時產生出
的報表就很不具有代表性。最理想的情況下，你會希望 MySQL Server 至少已經執行了一整天，這樣子一來你就可以確定報表中的資訊已包含了
Server 負載的高峰與低峰期，而不是隻包含其中之一。在範例報表中 Server 只執行了 34 分鐘，因此該報表的代表性是不足的，但因為這
只是用來做範例，也就沒什麼關係。
Key Report: Lines 3 - 7
第一個主要報告
區塊就是 Key Report，因為 Key(Indexes, 索引)是所有資訊中最重要的一項。雖然此報表無法告知您 Server 是否有善用
Index，但它可以告訴您 Server 對於 Shared Key Buffer 的使用狀態。請注意，這裡所指的 Key Buffer 是指
MyISAM Storage Engine 所使用的 Shared Key Buffer，InnoDB 所使用的 Key Buffer 並不包
含在內。
MySQL Server 支援許多種不同型別的資料表(比較正式的說法是 Storage Engine)，你可以將它們想象為各種不
同的資料結構，而不同的 Storage Engine 各有其優缺點。其中 MySQL Server 預設是使用
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：個別的 Connection 所需佔用的 Buffer
例如：
sort_buffer
myisam_sort_buffer
read_buffer
join_buffer
read_rnd_buffer ...等等計算 Server 至少需使用的總記憶體數量的方式為：
min_memory_needed = global_buffer + (thread_buffers * max_connection)
關
於 MySQL 的 Cache 機制有一點需要特別注意，各位應該都知道 MyISAM Storage Engine 將每個 table 分成三個
檔案儲存在硬碟之中，例如若您有一個資料表的名稱為 example，那麼您就會在硬碟上發現 example.FRM, example.MYD,
example.MYI 等三個檔案。這三個檔案所儲存的資料如下：
FRM： 儲存這個資料表的結構
MYD： Row Data，也就是你存在 example 資料表裡的資料
MYI： 此資料表的索引接下來是重點：
當 MySQL 要 Cache 某個資料表時，請問 MySQL 會 Cache 哪些資料？
答案是：
MySQL 只會 Cache 索引，也就是 *.MYI 檔案，而 Row Data(*.MYD) 則是交由作業系統來負責 Cache。
接
下來我們再回到 Key Buffer，有個很重要的問題我們一直沒有回答，就是『到底 Key Buffer 要設定多少才夠呢？』。如前所述，
MySQL 只會 Cache 索引(*.MYI)，因此您只要將資料庫中所有的 MYI 檔案加總起來，你就會知道大概要設為多少。
Buffer used: Line 4
身
為 MySQL 的管理者您通常會問的第一個問題是：『Server 到底用掉了多少 key buffer？』。如果您發現 MySQL 只使用了一小
部份的 Key Buffer，這並不是什麼需要注意的問題，因為 MySQL 只會在需要的時候才實際分配與使用 System RAM。也就是說，當
你設定 MySQL 可使用 512MB 的 RAM 時，並不代表 MySQL 啟動的時候將佔用 512MB 的 RAM(只有在 MySQL 認為
需要這麼做的時候才會)。報表中的第四行(Buffer used)指出 MySQL "曾經" 耗用過的最大記憶體數量，因此目前 "正在使用" 的記憶體
數量有可能少於（甚至大於）這個數字。MySQL 稱此數值為 "High Water Mark"，但在報表的下一行我們將會看到它並不總是如此。無論
如何，從 Buffer used 我們通常可以看出 key_buffer_size 這個系統變數值是否設定的夠大，如果你的 MySQL 已經使用
了 80~90% 以上的 Key Buffer，你就應該要調高 key_buffer_size。注意，Buffer used 永遠不會有使用率超
過 95% 的情況，因為 MySQL 的官方檔案中指出 Share Key Buffer 中有部份將會挪用給內部資料結構使用，因此當
Buffer used 指出 Share Key Buffer 的使用率高達 95% 時，其實在實務上等於是已使用了 100% 的
Share Key Buffer。在這個例子中 Server 只使用了 380KB(0.07%) 的 Share Key Buffer，看到這
裡也許您會判斷 Server 的 Share Key Buffer 是十分充足的，但請勿太早下定論，我們必須要接著考慮報表中的下一行才能做出客觀
的判斷......。
Current: Line 5
mysqlreport 使用
Key_blocks_unused 這個系統變數來決定目前 MySQL "正在使用" 的 Share Key Buffer 大小，只有在
MySQL Server 4.1.2 以上的版本才會有這個功能。如果報表中的上一行(Buffer used)真的有如 MySQL 官方檔案中所
說的是 "High Water Mark"，那麼 Current 所載明的數值應該永遠會小於或等於它。但在接下來的例子中我們將會看到，事情並不總
是如此。目前這臺 Server 已經使用了大約 60MB(12%) 的 Share Key Buffer，這是一個好現象因為它代表了你的
Share Key Buffer 仍然十分充足。Current 與 Buffer used 合在一起看即可提供一個很有用的指標，告訴您目前的
key_buffer_size 是否充足。
設定 key_buffer_size 的方式也很簡單，只要直接修改 MySQL 的設定檔然後重新啟動 Server 即可。例如若要將 Key Buffer 設定為 2000MB，則只要在 /etc/my.cnf 中加上：
[mysqld]
key_buffer_size=2000M
Write ratio: Line 6
索
引(Indexes, Keys)主要是在記憶體內(RAM-Based)進行操作的，索引之所以如此有用有部份原因就歸功於它們主要是在 RAM 裡面運
作，因此擁有極高的存取效能，不像儲存在硬碟中的資料存取速度非常慢。然而，不可否認的是 MySQL 終究還是必須從硬碟中將索引讀入 RAM 或是將
儲存在 RAM 中的索引寫回硬碟之中。Write ratio 標示著 MySQL 將索引寫入硬碟與 MySQL 將索引寫入 RAM 的比值
(Write Ratio = MySQL 將索引寫入硬碟的次數 / MySQL 將索引寫入 RAM 的次數)。具有接近於 1 的
Write Ratio 並不是一件很罕見的事，就像 MySQL 官方手冊中所說的，如果你的 MySQL 最主要的活動是 Update、
Insert 等等，那麼 Write Ratio 將會很接近於 1。Write Ratio 若大於 1 表示 MySQL 將索引寫入硬碟的次數大
於將索引寫入 RAM 的次數，很少有 MySQL Server 的 Write Ratio 會大於 1，絕大部份都應該會小於 1，即便是負載非常
重的 Server。
Read ratio: Line 7
Read Ratio 比
Write Ratio 來得重要一些，它標示了 MySQL 從硬碟讀取索引與從 RAM 讀取索引的比值(Read Ratio = MySQL
從硬碟讀取索引的次數 / MySQL 從 RAM 讀取索引的次數)。Read Ratio 的值應該要是 0.00 或 0.01，若大於這個值則表
示 Server 有問題需要進一步的調查，通常此問題的成因是 Share Key Buffer 設得太小造成 MySQL 需要不斷地從硬碟中讀取
所需要的索引資訊，而這個動作是十分沒有效率的並且完全抵消了使用索引可以帶來的好處。在 Server 剛啟動的頭一個小時 Read Ratio 很
常會出現大於 0.01 的數值，但 Server 執行過一陣子後它應該(也必須)降低至 0.01 或是 0.00。
Questions Report: Lines 9 - 26
第
二個主要的報表區塊，Questions，是第二重要的資訊，因為它可以告訴你 MySQL 到底都在忙些什麼事情。Questions 包含了
SQL queries 以及 MySQL protocol communications。大部份的人都只在意 Server 每秒可以處理多少查
詢(Queries Per Second, QPS)，但若以整個 Server 的觀點來考慮，QPS 其實是非常不精確的數值，它無法有效的告訴您
Server 的整體運作狀況。而 Questions 則提供了較完整的資訊，讓您一窺 Server 的全貌。
Total: Line 10
第
一個欄位單純的記載 MySQL 總共響應過多少查詢，第二個欄位則記錄響應的頻率(QPS)，當大部份的人說『我的 Server 平均每秒處理
XXX 個查詢』時，他們指的其實就是第二個欄位所記錄的響應頻率。此時你應該要反問他們『在那 XXX 個查詢之中，MySQL 到底做了哪些事
情？』，接下來 mysqlreport 將可以協助您回答此問題......。
Distribution of Total Queries (DTQ): Lines 11 - 15
所有的 Questions 可以大致區分為五個不同的類別：
1.Data Manipulation Statements (DMS)
2.query cache hits (QC Hits)
3.COM_QUIT
4.all other Com_ commands
5.Unknown
這
五個類別將會展示在 Lines 11 至 15，但它們的順序是會改變的。mysqlreport 預設是以查詢的總數(第一個欄位)來排序，次數越多
排得越上面，讓您可以快速的分辨出 MySQL 大部份時間都在忙些什麼東西。理想的情況下，你會希望 MySQL 把大部份的時間都花在 DMS 與
QC Hits 這兩個類別，因為這兩個類別才是真正在 "完成正事" 的類別。COM_QUIT、Com_、與 Unknown 也有其存在的必要，
但它們應該只佔了其中的一小部份。在繼續深入介紹之前，也許你會好奇第三個欄位是做什麼用的，它代表了該分類(例如 DMS)佔全部 Queries 的
百分比；若是在子分類(例如 Select)中，則表示該子分類佔所屬分類(例如 DMS)的百分比。在此範例中 DMS 佔了所有 Queries 的
82.84%，這是一個很好的現象。
Data manipulation statements(DMS) 包
含了：ELECT, INSERT, REPLACE, UPDATE, 與 DELETE(技術上來說，其實不只這幾個類別但
mysqlreport 只會用到這幾類)。基本上，你可以將 DMS 想成是 MySQL 真正有在做些 "有用的事" 的情況，因此你會希望
DMS 是 MySQL 最忙著處理的事情。
QC Hits
是 MySQL 不需要實際執行 Query 而只要直接從 Query Cache 中即可找到所需資料的次數。擁有高比例的 QC Hits 是讓人
夢寐以求的事，因為從 Query Cache 直接存取所需要的資料是十分快速且有效率的。然而大部份的 MySQL Server 因為各種原因，而
無法具有非常有效率的 Query Cache。在本範例中 QC Hits 佔了所有 Questions 的 16.91%，這是非常好的情況。然
而，千萬不要被這個數值給誤導了，在報表中的 38 至 45 行(Query Cache Report)將會告訴您完全不同的狀況。這是一個很好的範
例，展示了 mysqlreport 可以做為深入、相互參照與比對的分析工具。當 QC Hits 看來似乎十分完美時，這個 Server 的
Qeury Cache Report 卻可以明確的告訴您其實事情沒有表面上看起來的那樣完美，我們在稍後會在回到這個問題。
COM_QUIT 算是比較不重要的類別，若您不是真的很有興趣其實您大可忽略這個類別的內容。
COM_ 這
個類別代表著所有 MySQL 所執行過的指令，通常與 MySQL protocol 相關。在正常的情況下，你會希望這個類別所佔的比例越低越好，因
為當這個數值很高的時候就表示 MySQL 正忙碌於無關緊要的事情上。若這個數值很高通常代表 MySQL 正遭遇到某些很奇怪的問題，當我們深入討論
COM_ 的子類別的時候，我們會在回來探討這個問題。
Unknown 是
推論出來的類別，在理想的狀況下，之前所述的四個分類加總起來應該要等於 Questions 總數，但它們通常不會剛好等於。這是因為有些
Questions MySQL 在處理時會增加 Total Questions 的計數器，但卻沒有相對應的系統變數用來記錄所執行過的
Questions。在不同的 Server 上這個數值的變異很大，在有些 Server 上這個數值非常的高，在有些 Server 上則非常的
低，但在大部份的情況下它應該要維持在很低的水平才是。如果這個數值非常的高，可能代表 MySQL Server 有什麼地方出了問題。
Slow: Line 16
第 16
行非常的重要：它記錄了 MySQL 總共執行了多少次 Slow Query。Slow Query 就是指執行所需時間超過某個時間區間的
Query，例如執行超過 10 秒的 Query。用來判定是否為 Slow Query 的時間區間是可以透過 long_query_time
這個系統變數來設定的，MySQL 預設 long_query_time 為 10 秒，但通常我們會將它設定為 5 秒。在最理想的情況下，我們會希
望看到這個數值等於零，但通常這數值不會是零。一般來說 Slow Query 佔 Total Questions 的比例應該要低於 0.05，
Slow Query 的次數(第一個欄位)本身不是很重要，真正需要注意的是 Slow Query 佔 Total Questions 的比例，若
這比例偏高就代表 Server 有些問題需要解決。第四個欄位中的『%DMS: 』表示 Slow Query 在所有 DMS 中所佔的比例。
DMS: Lines 17 - 22
DMS
的子分類專案可以告訴我們，這臺 MySQL Server 是屬於哪一個型別的 MySQL Server，例如它是著重在 SELECT 操作或是
INSERT 操作，大部份的 MySQL Server 都是著重在 SELECT 操作。知道某臺 Server 是屬於哪一個型別的
MySQL Server 有助於我們思考報表中的其它資訊，例如一臺著重在 SELECT 操作的 MySQL Server 的
Write Ratio 應該會非常的接近 1，並有著較高的 Lock 時間。同時它也隱含了一個意義，就是也許你可以考慮使用
InnoDB Storage Engine，因為 MySQL 預設採用的 MyISAM Storage Engine 所提供的 Lock 層級
只有 Table Lock(只能針對整個資料表鎖定)，而 InnoDB 則提供 Row Lock 層級的鎖定機制(可只針對特定的 ROW 進行鎖
定，減少等待時間)。若是著重在 SELECT 操作的 Server，它的 Read Ratio 應該會接近於零，並有著非常低的
Table Lock 時間。
在範例中的 Server 是屬於著重在 SELECT 操作的 Server：65.72% 的
Questions 是 SELECT(第三個欄位)、79.33% 的 DMS Questions 是 SELECT(第四個欄位)。很明顯的，這
是臺著重在 SELECT 操作的 Server，知道了此項事實之後，我們才有辦法對其進行最佳化。
Com_: Lines 23 - 26
這個子分類只有在它的值偏高的時候才需要注意，因為過高的值表示 MySQL 正在忙著處理 "程式方面的東西"，而不是響應使用者的查詢。對大部份的 Server 來說這裡應該都不會出現偏高的數值，但您最好還是定期的檢查一下。
SELECT and Sort Report: Lines 28 - 36
大
致上來說，你只要注意第 29 行與第 31 行：Scan 與 Full Join。Scan 指的是有多少 SELECT statements 造
成 MySQL 需要進行 Full Table Scan。Full Join 的意思與 Scan 差不多，但它是適用在多個 Tables 相互
Join 在一起的情況。這二種情況的執行效能都非常的差，因此原則上你會希望這兩個數值越低越好。但這也不是絕對的，仍然要考慮實際的情況，例如雖然
Server 有很高比例的 Scan，但若這些 Scan 都是針對一些只有幾十筆資料的 table，那麼相對而言它依然是十分有效率的；但反之，
若這些 Scan 是針對具有上百萬筆資料的 table，那麼就會嚴重影響系統效能。
Query Cache Report: Lines 38 - 45
Query Cache Report 只有在 MySQL 有支援 Query Cache，以及 Query Cache 功能有開啟的情況下才會有這段資訊出現。
Memory usage: Line 39
此專案指出 Query Cache 的使用狀況，若系統已達到 Query Cache 的上限則會連帶影響到 Prunes Value，因為當配給的 Memory 不足時，MySQL 必須不斷地消除 RAM 中較不常使用的資料以挪出空間擺放新的資料。
Block Fragmnt: Line 40
這
個數值越高表示 Query Cache 的 Fragment 狀況越嚴重，通常它會界於 10%~20% 之間。在此範例中
Block Fragmnt 為 13.05%，這是可接受的情況，當然你也可以調整 query_cache_min_res_unit 的值來降低
Block Fragmnt。
Hits, Inserts, Prunes: Lines 41 - 43
Hits
是這三個數值中最重要的一項，因為它指出有多少 SELECT statements 是可直接從 Query Cache 裡面取得所需的資訊，此數值
越高就越好。Inserts 和 Prunes 最好是從第 44 行的比值來觀察比較容易理解。雖然 Prunes 的值偏高可能代表著
Query Cache 設得不夠大，但並不一定是如此。在本例中只有 55% 的 Query Cache 被使用，有著相對而言算低的
fragmentation 值，但 Prunes 值偏高，Prunes 的值(16/s)是 QC Hits 的兩倍。你可以想象這臺
Server 的 Query Cache 是一顆蘋果樹，它的樹枝被剪去的速度比你採收蘋果的速度還快。
Insrt:Prune and Hit:Insert Ratios: Lines 44 - 45
第 44
行中的 Insert 與 Prune 的比值可顯示 Query Cache 的揮發性。在一個高度穩定的 Query Cache 中，Insrt
的值應該要高於 Prune 的值；反之，在一個揮發性較高(較不穩定)的 Query Cache 中，這個比值將會是 1:1 或是偏重在
Prune 那方，這表示 Query Cache 中的資料有可能在使用到之前就已經被清除了。我們會希望擁有一個穩定的 Query Cache，
因為穩定的 Query Cache 表示那些被 Cache 在 Query Cache 中的資料會常被用到。高揮發性(較不穩定)的
Query Cache 代表兩件事情：第一，Query Cache 設得太小，需要加大。第二，MySQL 正試圖要 cache 所有的東西，甚
至是那些其實並不需要 cache 的資料。若是第一種狀況，只要單純的加大 Query Cache 即可。若是第二種情況，可能是 MySQL 試圖
要去 cache 所有可以 cache 的資料，你可以使用 SQL_NO_CACHE 來明確的告訴 MySQL 什麼資料是你不想要 cache
的。
Hit 與 Insert 的比值代表著 Query Cache 的有效性，理想的情況是我們新增了一些 Qeury 到
Query Cache 中，然後希望得到許多 Hits。因此若是這個 Query Cache 是有效率的，那麼該比值應該要偏重在左方。若比值是
偏重在 Insert 那方，那麼這個 Query Cache 的揮發性就太高了。考慮以下這個比值，若 Hit:Insert 為 1:1，那就表示
Query Cache 中的資料只使用了一次就被清除掉了，換句話說，我們放進去的資料比我們從裡面拿出來的資料還多，這樣一來就失去了使用
Query Cache 的意義。回想我們前面所提過的，雖然在本範例中 QC Hit 在全部的 Questions 中佔了很高的比例，但實際上我
們可以發現 QC 的有效性其實是很低的(Hit:Insert 的比值偏重在 Insert 那方)。若造成這個現象的原因是 MySQL 正試圖
cache 所有的東西，那麼將 Cache 模式改為 DEMAND 或許可以解決此問題。
Table Locks Report: Lines 47 - 49
這
個部份包含了兩項資訊：第一項是 Waited，代表 MySQL 需要等待以取得 table lock 的次數。第二項是 Immediate，表示
MySQL 不需要等待即可立刻取得 table lock 的次數。對資料庫來說『等待』幾乎可以肯定是一件很不好的事情，因此 Waited 的值
應該要越小越好。最具有代表性的是第三個欄位(Waited 佔所有 table lock 的百分比)，這個數值應該要小於 10%，大於這個值就表示
table/query 的索引設計不良或是有過多的 Slow Query。
Tables Report: Lines 51 - 53
Tables Report
同樣包含了二項資訊：第一是 Open，顯示目前正開啟的 table 數量、總共可開啟的最大數量，以及 Table Cache 的使用狀況。第二是
Opend，表示截至目前為止 MySQL 總共開啟過的 Table 數量，以及除上 Uptime 後的比值。這裡有兩件事值得注意：首先是
Table Cache 的使用狀況，100% 的 Table Cache 使用率並不是一件壞事但你可以試著調大 Table Cache 以增進
效能。第二是 MySQL 開啟 Table 的平均速率，若這個值很高則表示您的 table_cache 設得太小了，需要調大一些。一般來說，
MySQL 開啟 Table 的平均速率最好是小於 1/s。但大於這個數值也不一定就是壞事，有些調校良好且運作的十分有效率的
MySQL Server 其值為 7/s 並使用了 100% 的 Table Cache。
Connections Report: Lines 55 - 57
Connections Report
所代表的意義與 Tables Report 相似，請各位以此類推。比較需要注意的是：若你發現 Connections 的使用率接近 100%，也
許你會想調大 max_connections 的值以允許 MySQL 的 Client 建立更多聯機。然而，這通常是一種錯誤。我們常常可以發現很
多網路上的資料會教我們要調大 max_connections，但卻從來沒有給一個明確的理由。事實上，max_connections 的預設值
(100)，就算是對於負載十分沉重但有良好調校過的 Server 都已十分足夠。MySQL 對於單一聯機的資料處理通常只需要零點幾秒的時間即可完
成，就算是最大隻能使用 100 個聯機也夠讓你用上很長一段時間。若是您的 Server 有著非常高的最大聯機數(max connections)
或是單一聯機需要很長時間才可完成，那麼問題八成不是 max_connections 的值不夠大而是在別的地方，例如 slow queries、索
引設計不良、甚至是過於緩慢的 DNS 解析。在您將 max_connections 的值調到 100 以上之前，您應該要先確定真的是因為
Server 過於忙碌而需要調高此數值，而不是其它地方出了問題。每秒平均聯機數有可能會很高，事實上，若這個值很高而且 Server 的運作十分
順暢，那麼這通常會是一個好現象，無需擔心。大部份 Server 的每秒平均聯機數應該都會低於 5/s。
Created Temp Report: Lines 59 - 62
MySQL
可以建立暫時性的資料表，它可建立在硬碟中、檔案裡、或是 RAM 之中，而 Created Temp Report 則提供了相關的資料供您參考。這
些資料大多是相對而言，沒有一定的標準，但將暫時性的資料表建立在硬碟中是十分沒有效率的，因此 Disk table 的值最好是三者中最小的一個。當
暫時性的資料表被建立在硬碟中，表示此資料表沒有辦法被放進 RAM 裡面（因為 tmp_table_size 的值設得不夠大）。
Threads, Aborted, Bytes Reports: Lines 64 - 76
這
幾個部份大多沒什麼好解釋的，只有一個專案值得特別說明：第 66 行的最後一個欄位(%Hit)。每一個連線到 MySQL 的聯機都是由不同的
Thread 來處理，當 MySQL 啟動時會預先建立一些 Threads 並保留在 Thread Cache 中，如此一來 MySQL 就不
用一直忙著建立與刪除 Threads。但當每秒最大聯機數大於 MySQL 的 Thread Cache 時，MySQL 就會進入
Thread Thrash 的狀態：它不斷地建立新的 Threads 以滿足不斷增加的聯機的需求。當 Thread Thrash 發生時，%
Hit 的數值就會降低。在本範例中 %Hit 的值為 0.05%，這是非常不好的，因為它表示幾乎每一個新進來的聯機都會造成 MySQL 建立新的
Thread。我們可以看到在此範例中造成此現象的原兇就在第 66 行的第一個欄位，我們可以發現 Thread Cache 的值為 0，因此
thread_cache_size 的值需要調大。
話說回來，究竟 %Hit 接近於零真的有什麼關係嗎？Jeremy Zawondy 曾
在部落格上說到：Thread caching 並不是我們最需要關心的問題，但當你解決了所有其它更嚴重的問題之後，它就會是最嚴重的問題
官方網站：
軟體下載：
命令列選項的格式是 --選項，不過 -選項 的格式也可以。所有的選項都有其縮寫，只要是唯一的。例如，選項 --host 可以縮寫成 --ho，不過不能寫成 --h，因為 --h 有歧義，可能是 --host 或者 --help。
選項列表
--user USER
--password
--host ADDRESS
--port PORT
--socket SOCKET
--no-mycnf
--help
這些選項是模擬其他標準應用程式的。從 2.3 版本開始，--password 可以在後面加上引數，如 "--password
FOO"。如果命令列中只指定了選項 --password，則會提示輸入密碼。--no-mycnf 告訴 mysqlreport 不要讀取
~/.my.cnf，預設會去讀取這個檔案。--user 和 --password 總是覆蓋從 ~/.my.cnf 中取得的結果。
--infile FILE
直接從檔案中讀取狀態檔案，而不是從MySQL的 SHOW STATUS 中讀取。檔案內容通常是從 SHOW STATUS
的結果中取得，並且包含格式化字元(|, +, -)。mysqlreport 認為這樣的檔案"狀態名 數值"格式的，狀態包含字元和下劃線(A-Z
和 _)，數值則是非負整數。在狀態名和數值之間的任何內容都會被忽略。mysqlreport 也需要以下
MySQL伺服器系統變數
：version,
table_cache, max_connections, key_buffer_size, query_cache_size,
thread_cache_size。INFILE 的格式也可以是 "名字 =
數值"這樣的，名字可以使是上面提到的各種變數名，數值是非負整數，可能後面帶有M或者其他單位(根據版本不同而定)。例如，想要指定 18M 的
key_buffer_size：key_buffer_size = 18M。或者，256 個 table_cache：table_cache
= 256。M 指兆位元組，而非百萬。因此 18M 是 18,874,368，而非
18,000,000。如果這些伺服器變數沒有指定，則使用預設以下預設值：0.0.0, 64, 100, 8M, 0,
0，就可能會讓報告結果看起來很奇怪。
注意：MySQL 伺服器版本在 5.1.3 或更新時，儘管系統變數 table_cache 改成了 table_open_cache，但是讀取本地檔案時仍採用 table_cache。
--outfile FILE
在螢幕顯示完報告結果後，將結果寫入檔案中。mysqlreport
的內部機制總是先將結果寫入臨時檔案中。然後將該臨時檔案裡的內容列印到螢幕上。然後，如果指定了 --outfile 選項，則將臨時檔案複製成
OUTFILE。如果指定選項 --email，則會刪除臨時檔案。
--email ADDRESS
在螢幕顯示完結果後，將結果傳送到郵件地址 ADDRESS 中去。欲該選項，需要在 /usr/sbin/ 目錄下有 sendmail
程式，因此無法在 windows 平臺下使用。/usr/sbin/sendmail 可以符號連結到 qmail，或者任何其他能模擬
sendmail -t 方式的 MTA 程式。郵件來源是：mysqlreport，主題是：MySQL status report on
HOST，HOST 是 mysqlreport
所在的主機名，可能是讀取到的 --host 值，預設是 localhost。
--flush-status
顯示完報告後，執行 "FLUSH STATUS;" 語句。如果沒有許可權，則 DBD::mysql 會顯示返回值。
--relative (-r) X
mysqlreport 通常情況下報告的是自從 MySQL 伺服器啟動以來的狀態資訊。--relative 選項則是令 mysqlreport 產生一份自從上次報告以來的相關報告。
如
果 --relative X 的 X 值是一個整數，則 mysqlreport 會在隔 X 秒後再次產生一份 MySQL
伺服器的狀態報告。產生報告的次數是由 --report-count 選項來控制的。預設是產生 1 份相關的報告。例如，指定
--relative 的值為 60，則會產生 2 份報告：第一份會馬上生成，第二份會在 60
秒後再次生成。第二份報告中的數值會和前面的那份相關。例如，前面那份中總共有 10.00k 次查詢，在這 60 秒的間隔時間裡接受了新的
1.00k 次查詢，則第二份的報告中的總查詢次數是 1.00k 而非 11.00k 次。
如果
--relative 選項的值也可以是本地檔案(類似 --infile 選項的用法)，那麼 mysqlreport
會按照引數值中檔案的順序來依次產生狀態報告。因此，根據這些檔案產生的時間來指定選項的值非常重要：較早產生的檔案放在引數的前面。第一個檔案中必須有
手工新增的系統變數，例如：key_buffer_size、table_cache 等。每個檔案中可以有多組 "SHOW STATUS"
的結果。注意：透過 "mysqladmin -r -i N extended" 產生的狀態檔案無法使用，因為 mysqladmin 的 -r
引數已經令其產生了具有相對性的狀態值了。
由於 mysqlreport 首先會把狀態報告寫到臨時檔案中，如果 --relative 的值是 整數(而非 本地檔案)時，mysqlreport 會顯示它把檔案寫到哪了。那麼就可以直接透過檢視這些檔案內容來觀察伺服器的狀況了。
--report-count (-c) N
生成 N 份相關的報告。本選項只有在同時啟用 --relative 選項後才有效。mysqlreport 會自動產生 N+1 份報告：第一份基本報告，以及後面的 N 份相關報告。
--detach
若指定本選項，則 mysqlreport
會派生出程式來，不只是在螢幕顯示結果，還會轉入後臺繼續執行。派生新程式後，mysqlreport
會報告它把結果寫入哪個臨時檔案了。本選項還可以指定 --outfile 或 --email 的一個。如果沒有指定 --outfile 或
--email 的值，則產生的臨時檔案會被刪除，因為 mysqlreport 派生出新程式後，無法再將結果列印到終端螢幕上了。本選項如果和
--relative 一起使用的話就更有意義了，這樣 mysqlreport
就能定時報告資訊，而無需人工登入等方式在中斷執行了。使用如下的命令，就能讓 mysqlrepot
隔一個小時再次產生一次報告，並將結果傳送到自己的信箱中去：
mysqlreport -r 3600 -detach -email host@domain.com
一個小時候後，mysqlreport 透過email傳送報告，刪除臨時檔案，並且乾淨地終止。
--debug
顯示除錯資訊。
--dtq
(Questions 報告的 Total 部分中)顯示所有的查詢分佈報告。這些查詢主要包括以下四部分：DMS (見下面)、COM_ (見下面)、COM_QUIT(見
)、以及其他未知。每部分根據其總數倒序顯示。
--dms
(Questions 報告的 DMS 部分中)顯示所有的資料維護語句(DMS)報告。DMS是下面文件
13.2. Data Manipulation Statements
中提到的那些(當前主要有：SELECT, INSERT, REPLACE, UPDATE, and DELETE)。每個 DMS 根據其總數倒序顯示。
--com N
(Questions 報告之後)以降序顯示最多 N 個 非DMS Com_ 狀態值。如果沒有指定 N 的值，則預設是 3。所謂的非DMS Com_ 狀態值，包括：Com_change_db、Com_show_tables、Com_rollback 等。
--sas
(Questions 報告之後)，顯示所有的 Select_ 和 Sort_ 報告。詳情請看
。
--qcache
如果開啟查詢快取的話，則顯示查詢快取狀態報告。
--tab
(Create Temp 報告之後)顯示 執行緒、放棄的、流量 等狀態報告。從 mysqlreport v2.3 開始，執行緒狀態是從 Threads_ 狀態值讀取。
--innodb
顯示
InnoDB
狀態報告，包括MySQL 5.0.2以後才支援的InnoDB 緩衝池，以及5.0.3以後才支援的InnoDB鎖狀態報告。
--innodb-only
只顯示 InnoDB 報告；不顯示其他報告。
--dpr
顯示 InnoDB 資料，頁，行報告。
--all
如果可能，則顯示所有的狀態報告。一些報告，比如查詢快取、InnoDB等需要特定版本的MySQL或者其他特性才能支援。例如，儘管伺服器支援查詢快取，但是它被禁用了，則不管是否指定了 --qcache 或者 --all，都不會顯示查詢快取的報告。
mysqlreport
可將重要的 MySQL 系統資訊整理為具有較高可讀性的報表，使你更容易閱讀與深入理解目前 MySQL 的實際運作狀況。除了手動執行
SHOW STATUS 指令並以人眼去過濾與判斷目前的系統狀態以外，mysqlreport 大概是較好(八成也是唯一)的替代方案。
目前
的 mysqlreport 版本可以產生大量、具有完善資訊的報表，其報表完整的覆蓋了實務上所有重要的 MySQL 系統資訊，也可以產生只具有最重
要資訊的較精簡報表。完整的報表包含了 14 種不同面向，超過 121 行的完整資訊；精簡的報表包含了 6 種不同面向，總計 29 行的最重要信
息。
此檔案可教導您如何解讀 mysqlreport 所產生出來的各項資訊。如此一來，當您在閱讀 mysqlreport 所產生出來的報表時，您才可以回答最重要的問題：『MySQL Server 目前的運作狀況究竟如何？』
為了讓您有較深入的理解，此檔案將從報表的第一行開始逐項的解釋，當您閱讀完此檔案後，您應該具有完整的知識可以將 mysqlreport 佈署在任何 Server 上，並且有效的掌握 MySQL Server 的運作實況。
在開始之前，這裡有一份範例報表，我們將以此份報表為藍本開始進行教學。
（建議您將此報表列印出來和內文對照看，這樣子會比較容易理解文章內容）
PHP 語法:
1 MySQL 5.0.3 uptime 0 0:34:26 Fri Sep 1 19:46:02 2006
2
3 __ Key _________________________________________________________________
4 Buffer used 380.00k of 512.00M %Used: 0.07
5 Current 59.32M %Usage: 11.59
6 Write ratio 0.93
7 Read ratio 0.00
8
9 __ Questions ___________________________________________________________
10 Total 98.06k 47.46/s
11 DMS 81.23k 39.32/s %Total: 82.84
12 QC Hits 16.58k 8.02/s 16.91
13 COM_QUIT 200 0.10/s 0.20
14 Com_ 131 0.06/s 0.13
15 -Unknown 82 0.04/s 0.08
16 Slow 0 0.00/s 0.00 %DMS: 0.00
17 DMS 81.23k 39.32/s 82.84
18 SELECT 64.44k 31.19/s 65.72 79.33
19 INSERT 16.75k 8.11/s 17.08 20.61
20 UPDATE 41 0.02/s 0.04 0.05
21 REPLACE 0 0.00/s 0.00 0.00
22 DELETE 0 0.00/s 0.00 0.00
23 Com_ 131 0.06/s 0.13
24 change_db 119 0.06/s 0.12
25 show_fields 9 0.00/s 0.01
26 show_status 2 0.00/s 0.00
27
28 __ SELECT and Sort _____________________________________________________
29 Scan 38 0.02/s %SELECT: 0.06
30 Range 14 0.01/s 0.02
31 Full join 3 0.00/s 0.00
32 Range check 0 0.00/s 0.00
33 Full rng join 0 0.00/s 0.00
34 Sort scan 14 0.01/s
35 Sort range 26 0.01/s
36 Sort mrg pass 0 0.00/s
37
38 __ Query Cache _________________________________________________________
39 Memory usage 17.81M of 32.00M %Used: 55.66
40 Block Fragmnt 13.05%
41 Hits 16.58k 8.02/s
42 Inserts 48.50k 23.48/s
43 Prunes 33.46k 16.20/s
44 Insrt:Prune 1.45:1 7.28/s
45 Hit:Insert 0.34:1
46
47 __ Table Locks _________________________________________________________
48 Waited 1.01k 0.49/s %Total: 1.24
49 Immediate 80.04k 38.74/s
50
51 __ Tables ______________________________________________________________
52 Open 107 of 1024 %Cache: 10.45
53 Opened 118 0.06/s
54
55 __ Connections _________________________________________________________
56 Max used 77 of 600 %Max: 12.83
57 Total 202 0.10/s
58
59 __ Created Temp ________________________________________________________
60 Disk table 10 0.00/s
61 Table 26 0.01/s
62 File 3 0.00/s
63
64 __ Threads _____________________________________________________________
65 Running 55 of 77
66 Cache 0 %Hit: 0.5
67 Created 201 0.10/s
68 Slow 0 0.00/s
69
70 __ Aborted _____________________________________________________________
71 Clients 0 0.00/s
72 Connects 8 0.00/s
73
74 __ Bytes _______________________________________________________________
75 Sent 38.46M 18.62k/s
76 Received 7.98M 3.86k/s
Report Header: Line 1
報表的第一行包含了三樣不同的資訊：
MySQL Server 的版本、自上次啟動後已經過多少時間、目前 Server 的日期與時間。有些人會定時讓系統自動產生報表
(eg. cron)然後用程式去分析進行分析，此時表頭將可用來協助您辨識出不同時間點的報表。對於那些租用或使用虛擬主機的管理者，表頭可以協助您了
解自己所需面對的是什麼樣的 Server。MySQL Server 版本可以指出該 Server 有提供或沒有提供那些功能，而它的
Uptime 則表示該報表具有多大的代表性。Uptime 是重要的指標，可讓您瞭解此份報表所包含的資訊是否可能有偏誤，一般來說 Uptime
最少要有一小時會比較適當，甚至光是一小時其實也還不夠。例如您的 Server 可能已執行了六個小時，但此六小時皆是在使用率最低的午夜，此時產生出
的報表就很不具有代表性。最理想的情況下，你會希望 MySQL Server 至少已經執行了一整天，這樣子一來你就可以確定報表中的資訊已包含了
Server 負載的高峰與低峰期，而不是隻包含其中之一。在範例報表中 Server 只執行了 34 分鐘，因此該報表的代表性是不足的，但因為這
只是用來做範例，也就沒什麼關係。
Key Report: Lines 3 - 7
第一個主要報告
區塊就是 Key Report，因為 Key(Indexes, 索引)是所有資訊中最重要的一項。雖然此報表無法告知您 Server 是否有善用
Index，但它可以告訴您 Server 對於 Shared Key Buffer 的使用狀態。請注意，這裡所指的 Key Buffer 是指
MyISAM Storage Engine 所使用的 Shared Key Buffer，InnoDB 所使用的 Key Buffer 並不包
含在內。
MySQL Server 支援許多種不同型別的資料表(比較正式的說法是 Storage Engine)，你可以將它們想象為各種不
同的資料結構，而不同的 Storage Engine 各有其優缺點。其中 MySQL Server 預設是使用
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：個別的 Connection 所需佔用的 Buffer
例如：
sort_buffer
myisam_sort_buffer
read_buffer
join_buffer
read_rnd_buffer ...等等計算 Server 至少需使用的總記憶體數量的方式為：
min_memory_needed = global_buffer + (thread_buffers * max_connection)
關
於 MySQL 的 Cache 機制有一點需要特別注意，各位應該都知道 MyISAM Storage Engine 將每個 table 分成三個
檔案儲存在硬碟之中，例如若您有一個資料表的名稱為 example，那麼您就會在硬碟上發現 example.FRM, example.MYD,
example.MYI 等三個檔案。這三個檔案所儲存的資料如下：
FRM： 儲存這個資料表的結構
MYD： Row Data，也就是你存在 example 資料表裡的資料
MYI： 此資料表的索引接下來是重點：
當 MySQL 要 Cache 某個資料表時，請問 MySQL 會 Cache 哪些資料？
答案是：
MySQL 只會 Cache 索引，也就是 *.MYI 檔案，而 Row Data(*.MYD) 則是交由作業系統來負責 Cache。
接
下來我們再回到 Key Buffer，有個很重要的問題我們一直沒有回答，就是『到底 Key Buffer 要設定多少才夠呢？』。如前所述，
MySQL 只會 Cache 索引(*.MYI)，因此您只要將資料庫中所有的 MYI 檔案加總起來，你就會知道大概要設為多少。
Buffer used: Line 4
身
為 MySQL 的管理者您通常會問的第一個問題是：『Server 到底用掉了多少 key buffer？』。如果您發現 MySQL 只使用了一小
部份的 Key Buffer，這並不是什麼需要注意的問題，因為 MySQL 只會在需要的時候才實際分配與使用 System RAM。也就是說，當
你設定 MySQL 可使用 512MB 的 RAM 時，並不代表 MySQL 啟動的時候將佔用 512MB 的 RAM(只有在 MySQL 認為
需要這麼做的時候才會)。報表中的第四行(Buffer used)指出 MySQL "曾經" 耗用過的最大記憶體數量，因此目前 "正在使用" 的記憶體
數量有可能少於（甚至大於）這個數字。MySQL 稱此數值為 "High Water Mark"，但在報表的下一行我們將會看到它並不總是如此。無論
如何，從 Buffer used 我們通常可以看出 key_buffer_size 這個系統變數值是否設定的夠大，如果你的 MySQL 已經使用
了 80~90% 以上的 Key Buffer，你就應該要調高 key_buffer_size。注意，Buffer used 永遠不會有使用率超
過 95% 的情況，因為 MySQL 的官方檔案中指出 Share Key Buffer 中有部份將會挪用給內部資料結構使用，因此當
Buffer used 指出 Share Key Buffer 的使用率高達 95% 時，其實在實務上等於是已使用了 100% 的
Share Key Buffer。在這個例子中 Server 只使用了 380KB(0.07%) 的 Share Key Buffer，看到這
裡也許您會判斷 Server 的 Share Key Buffer 是十分充足的，但請勿太早下定論，我們必須要接著考慮報表中的下一行才能做出客觀
的判斷......。
Current: Line 5
mysqlreport 使用
Key_blocks_unused 這個系統變數來決定目前 MySQL "正在使用" 的 Share Key Buffer 大小，只有在
MySQL Server 4.1.2 以上的版本才會有這個功能。如果報表中的上一行(Buffer used)真的有如 MySQL 官方檔案中所
說的是 "High Water Mark"，那麼 Current 所載明的數值應該永遠會小於或等於它。但在接下來的例子中我們將會看到，事情並不總
是如此。目前這臺 Server 已經使用了大約 60MB(12%) 的 Share Key Buffer，這是一個好現象因為它代表了你的
Share Key Buffer 仍然十分充足。Current 與 Buffer used 合在一起看即可提供一個很有用的指標，告訴您目前的
key_buffer_size 是否充足。
設定 key_buffer_size 的方式也很簡單，只要直接修改 MySQL 的設定檔然後重新啟動 Server 即可。例如若要將 Key Buffer 設定為 2000MB，則只要在 /etc/my.cnf 中加上：
[mysqld]
key_buffer_size=2000M
Write ratio: Line 6
索
引(Indexes, Keys)主要是在記憶體內(RAM-Based)進行操作的，索引之所以如此有用有部份原因就歸功於它們主要是在 RAM 裡面運
作，因此擁有極高的存取效能，不像儲存在硬碟中的資料存取速度非常慢。然而，不可否認的是 MySQL 終究還是必須從硬碟中將索引讀入 RAM 或是將
儲存在 RAM 中的索引寫回硬碟之中。Write ratio 標示著 MySQL 將索引寫入硬碟與 MySQL 將索引寫入 RAM 的比值
(Write Ratio = MySQL 將索引寫入硬碟的次數 / MySQL 將索引寫入 RAM 的次數)。具有接近於 1 的
Write Ratio 並不是一件很罕見的事，就像 MySQL 官方手冊中所說的，如果你的 MySQL 最主要的活動是 Update、
Insert 等等，那麼 Write Ratio 將會很接近於 1。Write Ratio 若大於 1 表示 MySQL 將索引寫入硬碟的次數大
於將索引寫入 RAM 的次數，很少有 MySQL Server 的 Write Ratio 會大於 1，絕大部份都應該會小於 1，即便是負載非常
重的 Server。
Read ratio: Line 7
Read Ratio 比
Write Ratio 來得重要一些，它標示了 MySQL 從硬碟讀取索引與從 RAM 讀取索引的比值(Read Ratio = MySQL
從硬碟讀取索引的次數 / MySQL 從 RAM 讀取索引的次數)。Read Ratio 的值應該要是 0.00 或 0.01，若大於這個值則表
示 Server 有問題需要進一步的調查，通常此問題的成因是 Share Key Buffer 設得太小造成 MySQL 需要不斷地從硬碟中讀取
所需要的索引資訊，而這個動作是十分沒有效率的並且完全抵消了使用索引可以帶來的好處。在 Server 剛啟動的頭一個小時 Read Ratio 很
常會出現大於 0.01 的數值，但 Server 執行過一陣子後它應該(也必須)降低至 0.01 或是 0.00。
Questions Report: Lines 9 - 26
第
二個主要的報表區塊，Questions，是第二重要的資訊，因為它可以告訴你 MySQL 到底都在忙些什麼事情。Questions 包含了
SQL queries 以及 MySQL protocol communications。大部份的人都只在意 Server 每秒可以處理多少查
詢(Queries Per Second, QPS)，但若以整個 Server 的觀點來考慮，QPS 其實是非常不精確的數值，它無法有效的告訴您
Server 的整體運作狀況。而 Questions 則提供了較完整的資訊，讓您一窺 Server 的全貌。
Total: Line 10
第
一個欄位單純的記載 MySQL 總共響應過多少查詢，第二個欄位則記錄響應的頻率(QPS)，當大部份的人說『我的 Server 平均每秒處理
XXX 個查詢』時，他們指的其實就是第二個欄位所記錄的響應頻率。此時你應該要反問他們『在那 XXX 個查詢之中，MySQL 到底做了哪些事
情？』，接下來 mysqlreport 將可以協助您回答此問題......。
Distribution of Total Queries (DTQ): Lines 11 - 15
所有的 Questions 可以大致區分為五個不同的類別：
1.Data Manipulation Statements (DMS)
2.query cache hits (QC Hits)
3.COM_QUIT
4.all other Com_ commands
5.Unknown
這
五個類別將會展示在 Lines 11 至 15，但它們的順序是會改變的。mysqlreport 預設是以查詢的總數(第一個欄位)來排序，次數越多
排得越上面，讓您可以快速的分辨出 MySQL 大部份時間都在忙些什麼東西。理想的情況下，你會希望 MySQL 把大部份的時間都花在 DMS 與
QC Hits 這兩個類別，因為這兩個類別才是真正在 "完成正事" 的類別。COM_QUIT、Com_、與 Unknown 也有其存在的必要，
但它們應該只佔了其中的一小部份。在繼續深入介紹之前，也許你會好奇第三個欄位是做什麼用的，它代表了該分類(例如 DMS)佔全部 Queries 的
百分比；若是在子分類(例如 Select)中，則表示該子分類佔所屬分類(例如 DMS)的百分比。在此範例中 DMS 佔了所有 Queries 的
82.84%，這是一個很好的現象。
Data manipulation statements(DMS) 包
含了：ELECT, INSERT, REPLACE, UPDATE, 與 DELETE(技術上來說，其實不只這幾個類別但
mysqlreport 只會用到這幾類)。基本上，你可以將 DMS 想成是 MySQL 真正有在做些 "有用的事" 的情況，因此你會希望
DMS 是 MySQL 最忙著處理的事情。
QC Hits
是 MySQL 不需要實際執行 Query 而只要直接從 Query Cache 中即可找到所需資料的次數。擁有高比例的 QC Hits 是讓人
夢寐以求的事，因為從 Query Cache 直接存取所需要的資料是十分快速且有效率的。然而大部份的 MySQL Server 因為各種原因，而
無法具有非常有效率的 Query Cache。在本範例中 QC Hits 佔了所有 Questions 的 16.91%，這是非常好的情況。然
而，千萬不要被這個數值給誤導了，在報表中的 38 至 45 行(Query Cache Report)將會告訴您完全不同的狀況。這是一個很好的範
例，展示了 mysqlreport 可以做為深入、相互參照與比對的分析工具。當 QC Hits 看來似乎十分完美時，這個 Server 的
Qeury Cache Report 卻可以明確的告訴您其實事情沒有表面上看起來的那樣完美，我們在稍後會在回到這個問題。
COM_QUIT 算是比較不重要的類別，若您不是真的很有興趣其實您大可忽略這個類別的內容。
COM_ 這
個類別代表著所有 MySQL 所執行過的指令，通常與 MySQL protocol 相關。在正常的情況下，你會希望這個類別所佔的比例越低越好，因
為當這個數值很高的時候就表示 MySQL 正忙碌於無關緊要的事情上。若這個數值很高通常代表 MySQL 正遭遇到某些很奇怪的問題，當我們深入討論
COM_ 的子類別的時候，我們會在回來探討這個問題。
Unknown 是
推論出來的類別，在理想的狀況下，之前所述的四個分類加總起來應該要等於 Questions 總數，但它們通常不會剛好等於。這是因為有些
Questions MySQL 在處理時會增加 Total Questions 的計數器，但卻沒有相對應的系統變數用來記錄所執行過的
Questions。在不同的 Server 上這個數值的變異很大，在有些 Server 上這個數值非常的高，在有些 Server 上則非常的
低，但在大部份的情況下它應該要維持在很低的水平才是。如果這個數值非常的高，可能代表 MySQL Server 有什麼地方出了問題。
Slow: Line 16
第 16
行非常的重要：它記錄了 MySQL 總共執行了多少次 Slow Query。Slow Query 就是指執行所需時間超過某個時間區間的
Query，例如執行超過 10 秒的 Query。用來判定是否為 Slow Query 的時間區間是可以透過 long_query_time
這個系統變數來設定的，MySQL 預設 long_query_time 為 10 秒，但通常我們會將它設定為 5 秒。在最理想的情況下，我們會希
望看到這個數值等於零，但通常這數值不會是零。一般來說 Slow Query 佔 Total Questions 的比例應該要低於 0.05，
Slow Query 的次數(第一個欄位)本身不是很重要，真正需要注意的是 Slow Query 佔 Total Questions 的比例，若
這比例偏高就代表 Server 有些問題需要解決。第四個欄位中的『%DMS: 』表示 Slow Query 在所有 DMS 中所佔的比例。
DMS: Lines 17 - 22
DMS
的子分類專案可以告訴我們，這臺 MySQL Server 是屬於哪一個型別的 MySQL Server，例如它是著重在 SELECT 操作或是
INSERT 操作，大部份的 MySQL Server 都是著重在 SELECT 操作。知道某臺 Server 是屬於哪一個型別的
MySQL Server 有助於我們思考報表中的其它資訊，例如一臺著重在 SELECT 操作的 MySQL Server 的
Write Ratio 應該會非常的接近 1，並有著較高的 Lock 時間。同時它也隱含了一個意義，就是也許你可以考慮使用
InnoDB Storage Engine，因為 MySQL 預設採用的 MyISAM Storage Engine 所提供的 Lock 層級
只有 Table Lock(只能針對整個資料表鎖定)，而 InnoDB 則提供 Row Lock 層級的鎖定機制(可只針對特定的 ROW 進行鎖
定，減少等待時間)。若是著重在 SELECT 操作的 Server，它的 Read Ratio 應該會接近於零，並有著非常低的
Table Lock 時間。
在範例中的 Server 是屬於著重在 SELECT 操作的 Server：65.72% 的
Questions 是 SELECT(第三個欄位)、79.33% 的 DMS Questions 是 SELECT(第四個欄位)。很明顯的，這
是臺著重在 SELECT 操作的 Server，知道了此項事實之後，我們才有辦法對其進行最佳化。
Com_: Lines 23 - 26
這個子分類只有在它的值偏高的時候才需要注意，因為過高的值表示 MySQL 正在忙著處理 "程式方面的東西"，而不是響應使用者的查詢。對大部份的 Server 來說這裡應該都不會出現偏高的數值，但您最好還是定期的檢查一下。
SELECT and Sort Report: Lines 28 - 36
大
致上來說，你只要注意第 29 行與第 31 行：Scan 與 Full Join。Scan 指的是有多少 SELECT statements 造
成 MySQL 需要進行 Full Table Scan。Full Join 的意思與 Scan 差不多，但它是適用在多個 Tables 相互
Join 在一起的情況。這二種情況的執行效能都非常的差，因此原則上你會希望這兩個數值越低越好。但這也不是絕對的，仍然要考慮實際的情況，例如雖然
Server 有很高比例的 Scan，但若這些 Scan 都是針對一些只有幾十筆資料的 table，那麼相對而言它依然是十分有效率的；但反之，
若這些 Scan 是針對具有上百萬筆資料的 table，那麼就會嚴重影響系統效能。
Query Cache Report: Lines 38 - 45
Query Cache Report 只有在 MySQL 有支援 Query Cache，以及 Query Cache 功能有開啟的情況下才會有這段資訊出現。
Memory usage: Line 39
此專案指出 Query Cache 的使用狀況，若系統已達到 Query Cache 的上限則會連帶影響到 Prunes Value，因為當配給的 Memory 不足時，MySQL 必須不斷地消除 RAM 中較不常使用的資料以挪出空間擺放新的資料。
Block Fragmnt: Line 40
這
個數值越高表示 Query Cache 的 Fragment 狀況越嚴重，通常它會界於 10%~20% 之間。在此範例中
Block Fragmnt 為 13.05%，這是可接受的情況，當然你也可以調整 query_cache_min_res_unit 的值來降低
Block Fragmnt。
Hits, Inserts, Prunes: Lines 41 - 43
Hits
是這三個數值中最重要的一項，因為它指出有多少 SELECT statements 是可直接從 Query Cache 裡面取得所需的資訊，此數值
越高就越好。Inserts 和 Prunes 最好是從第 44 行的比值來觀察比較容易理解。雖然 Prunes 的值偏高可能代表著
Query Cache 設得不夠大，但並不一定是如此。在本例中只有 55% 的 Query Cache 被使用，有著相對而言算低的
fragmentation 值，但 Prunes 值偏高，Prunes 的值(16/s)是 QC Hits 的兩倍。你可以想象這臺
Server 的 Query Cache 是一顆蘋果樹，它的樹枝被剪去的速度比你採收蘋果的速度還快。
Insrt:Prune and Hit:Insert Ratios: Lines 44 - 45
第 44
行中的 Insert 與 Prune 的比值可顯示 Query Cache 的揮發性。在一個高度穩定的 Query Cache 中，Insrt
的值應該要高於 Prune 的值；反之，在一個揮發性較高(較不穩定)的 Query Cache 中，這個比值將會是 1:1 或是偏重在
Prune 那方，這表示 Query Cache 中的資料有可能在使用到之前就已經被清除了。我們會希望擁有一個穩定的 Query Cache，
因為穩定的 Query Cache 表示那些被 Cache 在 Query Cache 中的資料會常被用到。高揮發性(較不穩定)的
Query Cache 代表兩件事情：第一，Query Cache 設得太小，需要加大。第二，MySQL 正試圖要 cache 所有的東西，甚
至是那些其實並不需要 cache 的資料。若是第一種狀況，只要單純的加大 Query Cache 即可。若是第二種情況，可能是 MySQL 試圖
要去 cache 所有可以 cache 的資料，你可以使用 SQL_NO_CACHE 來明確的告訴 MySQL 什麼資料是你不想要 cache
的。
Hit 與 Insert 的比值代表著 Query Cache 的有效性，理想的情況是我們新增了一些 Qeury 到
Query Cache 中，然後希望得到許多 Hits。因此若是這個 Query Cache 是有效率的，那麼該比值應該要偏重在左方。若比值是
偏重在 Insert 那方，那麼這個 Query Cache 的揮發性就太高了。考慮以下這個比值，若 Hit:Insert 為 1:1，那就表示
Query Cache 中的資料只使用了一次就被清除掉了，換句話說，我們放進去的資料比我們從裡面拿出來的資料還多，這樣一來就失去了使用
Query Cache 的意義。回想我們前面所提過的，雖然在本範例中 QC Hit 在全部的 Questions 中佔了很高的比例，但實際上我
們可以發現 QC 的有效性其實是很低的(Hit:Insert 的比值偏重在 Insert 那方)。若造成這個現象的原因是 MySQL 正試圖
cache 所有的東西，那麼將 Cache 模式改為 DEMAND 或許可以解決此問題。
Table Locks Report: Lines 47 - 49
這
個部份包含了兩項資訊：第一項是 Waited，代表 MySQL 需要等待以取得 table lock 的次數。第二項是 Immediate，表示
MySQL 不需要等待即可立刻取得 table lock 的次數。對資料庫來說『等待』幾乎可以肯定是一件很不好的事情，因此 Waited 的值
應該要越小越好。最具有代表性的是第三個欄位(Waited 佔所有 table lock 的百分比)，這個數值應該要小於 10%，大於這個值就表示
table/query 的索引設計不良或是有過多的 Slow Query。
Tables Report: Lines 51 - 53
Tables Report
同樣包含了二項資訊：第一是 Open，顯示目前正開啟的 table 數量、總共可開啟的最大數量，以及 Table Cache 的使用狀況。第二是
Opend，表示截至目前為止 MySQL 總共開啟過的 Table 數量，以及除上 Uptime 後的比值。這裡有兩件事值得注意：首先是
Table Cache 的使用狀況，100% 的 Table Cache 使用率並不是一件壞事但你可以試著調大 Table Cache 以增進
效能。第二是 MySQL 開啟 Table 的平均速率，若這個值很高則表示您的 table_cache 設得太小了，需要調大一些。一般來說，
MySQL 開啟 Table 的平均速率最好是小於 1/s。但大於這個數值也不一定就是壞事，有些調校良好且運作的十分有效率的
MySQL Server 其值為 7/s 並使用了 100% 的 Table Cache。
Connections Report: Lines 55 - 57
Connections Report
所代表的意義與 Tables Report 相似，請各位以此類推。比較需要注意的是：若你發現 Connections 的使用率接近 100%，也
許你會想調大 max_connections 的值以允許 MySQL 的 Client 建立更多聯機。然而，這通常是一種錯誤。我們常常可以發現很
多網路上的資料會教我們要調大 max_connections，但卻從來沒有給一個明確的理由。事實上，max_connections 的預設值
(100)，就算是對於負載十分沉重但有良好調校過的 Server 都已十分足夠。MySQL 對於單一聯機的資料處理通常只需要零點幾秒的時間即可完
成，就算是最大隻能使用 100 個聯機也夠讓你用上很長一段時間。若是您的 Server 有著非常高的最大聯機數(max connections)
或是單一聯機需要很長時間才可完成，那麼問題八成不是 max_connections 的值不夠大而是在別的地方，例如 slow queries、索
引設計不良、甚至是過於緩慢的 DNS 解析。在您將 max_connections 的值調到 100 以上之前，您應該要先確定真的是因為
Server 過於忙碌而需要調高此數值，而不是其它地方出了問題。每秒平均聯機數有可能會很高，事實上，若這個值很高而且 Server 的運作十分
順暢，那麼這通常會是一個好現象，無需擔心。大部份 Server 的每秒平均聯機數應該都會低於 5/s。
Created Temp Report: Lines 59 - 62
MySQL
可以建立暫時性的資料表，它可建立在硬碟中、檔案裡、或是 RAM 之中，而 Created Temp Report 則提供了相關的資料供您參考。這
些資料大多是相對而言，沒有一定的標準，但將暫時性的資料表建立在硬碟中是十分沒有效率的，因此 Disk table 的值最好是三者中最小的一個。當
暫時性的資料表被建立在硬碟中，表示此資料表沒有辦法被放進 RAM 裡面（因為 tmp_table_size 的值設得不夠大）。
Threads, Aborted, Bytes Reports: Lines 64 - 76
這
幾個部份大多沒什麼好解釋的，只有一個專案值得特別說明：第 66 行的最後一個欄位(%Hit)。每一個連線到 MySQL 的聯機都是由不同的
Thread 來處理，當 MySQL 啟動時會預先建立一些 Threads 並保留在 Thread Cache 中，如此一來 MySQL 就不
用一直忙著建立與刪除 Threads。但當每秒最大聯機數大於 MySQL 的 Thread Cache 時，MySQL 就會進入
Thread Thrash 的狀態：它不斷地建立新的 Threads 以滿足不斷增加的聯機的需求。當 Thread Thrash 發生時，%
Hit 的數值就會降低。在本範例中 %Hit 的值為 0.05%，這是非常不好的，因為它表示幾乎每一個新進來的聯機都會造成 MySQL 建立新的
Thread。我們可以看到在此範例中造成此現象的原兇就在第 66 行的第一個欄位，我們可以發現 Thread Cache 的值為 0，因此
thread_cache_size 的值需要調大。
話說回來，究竟 %Hit 接近於零真的有什麼關係嗎？Jeremy Zawondy 曾
在部落格上說到：Thread caching 並不是我們最需要關心的問題，但當你解決了所有其它更嚴重的問題之後，它就會是最嚴重的問題
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/21601207/viewspace-682185/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- MySQL監控工具MySql
- 效能監控工具YourKit
- JVM 效能監控工具JVM
- CentOS效能監控工具CentOS
- MySQL監控工具-orztopMySql
- MySQL監控工具-orzdbaMySql
- mysql效能監控相關MySql
- mysql效能監控指標MySql指標
- MySQL監控工具之orzdbaMySql
- 效能監控和分析工具--nmon
- Mysql效能監控視覺化MySql視覺化
- Flutter效能監控工具（3）--- Observatory使用Flutter
- Centos效能監控工具——netdata配置CentOS
- Java效能監控工具:VisualVMJavaLVM
- Android的效能監控工具StrictModeAndroid
- Flutter效能監控工具（2）— Performance OverlayFlutterORM
- MYSQL和SQLServer效能監控指標MySqlServer指標
- ☕[JVM效能專題]（1）效能監控-命令列工具JVM命令列
- Flutter效能監控工具（1）--- Observatory簡介Flutter
- 效能監控工具之Grafana+Prometheus+ExportersGrafanaPrometheusExport
- 深入理解JVM（七）——效能監控工具JVM
- mysql 5.6效能監控表innodb_metricsMySql
- MySQL調優效能監控之show profileMySql
- MySQL調優效能監控之performance schemaMySqlORM
- Jmeter系列（38）- 詳解效能監控工具 nmonJMeter
- 效能測試監控工具--Jmeter + Grafana + InfluxDBJMeterGrafanaUX
- 深入理解JVM：效能分析與監控工具JVM
- Netflix效能監控工具Vector介紹
- 利用OSW工具監控作業系統效能作業系統
- linux效能監控工具——NAGIOS和OVOLinuxiOS
- Mytop工具來監控MySQL資源MySql
- 巧用Zabbix自定義監控Mysql效能狀態MySql
- 前端效能監控前端
- php效能監控PHP
- 5分鐘打造一個前端效能監控工具前端
- 5 分鐘擼一個前端效能監控工具前端
- 最強效能監控工具之Grafana+Prometheus+ExportersGrafanaPrometheusExport
- OpManager--強大的網路效能監控工具