MySQLReport 報告說明

MySQLReport 報告說明

---

Report Header

MySQL 5.0.3 uptime 0 0:34:26 Fri Sep 1 19:46:02 2006
MySQL Server 的版本、自上次啟動後已經過多少時間、目前 Server 的日期與時間

key report
MySQL Server的Buffer分為Global Buffer和Thread Buffer

計算 Server 至少需使用的總記憶體數量的方式為：
min_memory_needed = global_buffer + (thread_buffers * max_connection)

MyISAM Storage Engine 將每個 table 分成三個檔案儲存在硬碟之中.

FRM： 儲存這個資料表的結構
MYD： Row Data，也就是你存在 example 資料表裡的資料
MYI： 此資料表的索引

Buffer used 380.00k of 512.00M %Used: 0.07
Current 59.32M %Usage: 11.59
Write ratio 0.93
Read ratio 0.00

1:Buffer used指出 MySQL “曾經” 耗用過的最大記憶體數量，因此目前 “正在使用” 的記憶體數量有可能少於（甚至大於）這個數字。MySQL 稱此數值為 “High Water Mark”
如果你的 MySQL 已經使用了 80~90% 以上的 Key Buffer，你就應該要調高 key_buffer_size.

2:Current表示 Key_blocks_unused 這個系統變數來決定目前 MySQL “正在使用” 的 Share Key Buffer 大小

索引(Indexes, Keys)主要是在記憶體內(RAM-Based)進行操作的，索引之所以如此有用有部份原因就歸功於它們主要是在 RAM 裡面運作，因此擁有極高的存取效能，不像儲存在硬碟中的資料存取速度非常慢。然而，不可否認的是 MySQL 終究還是必須從硬碟中將索引讀入 RAM 或是將儲存在 RAM 中的索引寫回硬碟之中

3:Write ratio 標示著 MySQL 將索引寫入硬碟與 MySQL 將索引寫入 RAM 的比值(Write Ratio = MySQL 將索引寫入硬碟的次數 / MySQL 將索引寫入 RAM 的次數)。具有接近於1 的Write Ratio 並不是一件很罕見的事，就像 MySQL 官方手冊中所說的，如果你的 MySQL 最主要的活動是 Update、Insert 等等，那麼 Write Ratio 將會很接近於1

4:Read Ratio 比 Write Ratio 來得重要一些，它標示了 MySQL 從硬碟讀取索引與從 RAM 讀取索引的比值(Read Ratio = MySQL 從硬碟讀取索引的次數 / MySQL 從 RAM 讀取索引的次數)。Read Ratio 的值應該要是 0.00 或 0.01，若大於這個值則表示 Server 有問題需要進一步的調查，通常此問題的成因是 Share Key Buffer 設得太小造成 MySQL 需要不斷地從硬碟中讀取所需要的索引資訊，而這個動作是十分沒有效率的並且完全抵消了使用索引可以帶來的好處。
Questions Report
Questions是第二重要的資訊，因為它可以告訴你 MySQL 到底都在忙些什麼事情。Questions 包含了 SQL queries 以及 MySQL protocol communications。大部份的人都只在意 Server 每秒可以處理多少查詢(Queries Per Second, QPS)，但若以整個 Server 的觀點來考慮，QPS 其實是非常不精確的數值，它無法有效的告訴您 Server 的整體運作狀況

Total 98.06k 47.46/s
DMS 81.23k 39.32/s %Total: 82.84
QC Hits 16.58k 8.02/s 16.91
COM_QUIT 200 0.10/s 0.20
Com_ 131 0.06/s 0.13
-Unknown 82 0.04/s 0.08
Slow 0 0.00/s 0.00 %DMS: 0.00
DMS 81.23k 39.32/s 82.84
SELECT 64.44k 31.19/s 65.72 79.33
INSERT 16.75k 8.11/s 17.08 20.61
UPDATE 41 0.02/s 0.04 0.05
REPLACE 0 0.00/s 0.00 0.00
DELETE 0 0.00/s 0.00 0.00
Com_ 131 0.06/s 0.13
change_db 119 0.06/s 0.12
show_fields 9 0.00/s 0.01
show_status 2 0.00/s 0.00

1:Total 表示
純的記載 MySQL 總共響應過多少查詢，第二個欄位則記錄響應的頻率(QPS)

2:Distribution of Total Queries (DTQ):
所有的 Questions 可以大致區分為五個不同的類別：
1.Data Manipulation Statements (DMS)
2.query cache hits (QC Hits)
3.COM_QUIT
4.all other Com_ commands
5.Unknown

理想的情況下，你會希望 MySQL 把大部份的時間都花在 DMS 與 QC Hits 這兩個類別，因為這兩個類別才是真正在 “完成正事” 的類別

3:Data manipulation statements(DMS) 包含了：ELECT, INSERT, REPLACE, UPDATE, 與 DELETE(技術上來說，其實不只這幾個類別但mysqlreport 只會用到這幾類)。基本上，你可以將 DMS 想成是 MySQL 真正有在做些 “有用的事” 的情況，因此你會希望 DMS 是 MySQL 最忙著處理的事情。

4:QC Hits 是 MySQL 不需要實際執行 Query 而只要直接從 Query Cache 中即可找到所需資料的次數。擁有高比例的 QC Hits 是讓人夢寐以求的事，因為從 Query Cache 直接存取所需要的資料是十分快速且有效率的。然而大部份的 MySQL Server 因為各種原因，而無法具有非常有效率的 Query Cache

5:COM_ 這個類別代表著所有 MySQL 所執行過的指令，通常與 MySQL protocol 相關。在正常的情況下，你會希望這個類別所佔的比例越低越好，因為當這個數值很高的時候就表示 MySQL 正忙碌於無關緊要的事情上

Slow
表示它記錄了 MySQL 總共執行了多少次 Slow Query。Slow Query 就是指執行所需時間超過某個時間區間的 Query。一般來說 Slow Query 佔 Total Questions 的比例應該要低於 0.05，Slow Query 的次數(第一個欄位)本身不是很重要，真正需要注意的是

Slow Query 佔 Total Questions 的比例，若這比例偏高就代表 Server 有些問題需要解決
DMS 81.23k 39.32/s 82.84
SELECT 64.44k 31.19/s 65.72 79.33
INSERT 16.75k 8.11/s 17.08 20.61
UPDATE 41 0.02/s 0.04 0.05
REPLACE 0 0.00/s 0.00 0.00
DELETE 0 0.00/s 0.00 0.00

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 時間。

SELECT and Sort Report

Scan 38 0.02/s %SELECT: 0.06
Range 14 0.01/s 0.02
Full join 3 0.00/s 0.00
Range check 0 0.00/s 0.00
Full rng join 0 0.00/s 0.00
Sort scan 14 0.01/s
Sort range 26 0.01/s
Sort mrg pass 0 0.00/s

大致上來說，你只要注意Scan 與 Full Join。Scan 指的是有多少 SELECT statements 造成 MySQL 需要進行 Full Table Scan。Full Join 的意思與 Scan 差不多，但它是適用在多個 Tables 相互 Join 在一起的情況。這二種情況的執行效能都非常的差，因此原則上你會希望這兩個數值越低越好。

Query Cache Report

Memory usage 17.81M of 32.00M %Used: 55.66
Block Fragmnt 13.05%
Hits 16.58k 8.02/s
Inserts 48.50k 23.48/s
Prunes 33.46k 16.20/s
Insrt:Prune 1.45:1 7.28/s
Hit:Insert 0.34:1

Query Cache Report 只有在 MySQL 有支援 Query Cache，以及 Query Cache 功能有開啟的情況下才會有這段資訊出現。

(1)Memory usage 表示此專案指出 Query Cache 的使用狀況

(2)Block Fragmnt 表示塊碎片,通常它會界於 10%~20% 之間

(3)Hits, Inserts, Prunes

Table Locks Report

Waited 1.01k 0.49/s %Total: 1.24
Immediate 80.04k 38.74/s

這個部份包含了兩項資訊：第一項是 Waited，代表 MySQL 需要等待以取得 table lock 的次數。第二項是 Immediate，表示 MySQL 不需要等待即可立刻取得 table lock 的次數

Tables Report

Open 107 of 1024 %Cache: 10.45
Opened 118 0.06/s

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

Max used 77 of 600 %Max: 12.83
Total 202 0.10/s

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

Disk table 10 0.00/s
Table 26 0.01/s
File 3 0.00/s

MySQL 可以建立暫時性的資料表，它可建立在硬碟中、檔案裡、或是 RAM 之中，而 Created Temp Report 則提供了相關的資料供您參考。這些資料大多是相對而言，沒有一定的標準，但將暫時性的資料表建立在硬碟中是十分沒有效率的，因此 Disk table 的值最好是三者中最小的一個。當暫時性的資料表被建立在硬碟中，表示此資料表沒有辦法被放進 RAM 裡面（因為 tmp_table_size 的值設得不夠大）。

Threads, Aborted, Bytes Reports

Running 55 of 77
Cache 0 %Hit: 0.5
Created 201 0.10/s
Slow 0 0.00/s

這幾個部份大多沒什麼好解釋的，只有一個專案值得特別說明：第 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 的值需要調大

mysqlreport中的innodb部分詳解


__ InnoDB Buffer Pool __________________________________________________
Usage 7.97M of 8.00M %Used: 99.61
Read hit 100.00%

Pages
Free 2 %Total: 0.39
Data 499 97.46 %Drty: 0.00
Misc 11 2.15
Latched 0 0.00

Reads 101.06M 8.5/s
From file 373 0.0/s 0.00
Ahead Rnd 19 0.0/s
Ahead Sql 13 0.0/s

Writes 860.88k 0.1/s
Flushes 254.62k 0.0/s
Wait Free 0 0/s

__ InnoDB Lock _________________________________________________________
Waits 424 0.0/s
Current 0
Time acquiring
Total 254266 ms
Average 599 ms
Max 39559 ms

__ InnoDB Data, Pages, Rows ____________________________________________
Data
Reads 502 0.0/s
Writes 344.09k 0.0/s
fsync 158.03k 0.0/s
Pending
Reads 0
Writes 0
fsync 0

Pages
Created 699 0.0/s
Read 523 0.0/s
Written 254.62k 0.0/s

Rows
Deleted 4.59k 0.0/s
Inserted 74.16k 0.0/s
Read 94.67M 8.0/s
Updated 40.61k 0.0/s

第一區塊, 展示了 mysql innodb 的快取統計資訊.
其中, innodb跟myisam的快取機制有較大區別, innodb不僅快取索引,還快取一些表資料.而myisam只快取索引.

Usage 7.97M of 8.00M %Used: 99.61
Read hit 100.00%

Usage 表示, 總的快取中, 當前已佔用 7.97M, 使用率達 99.61%. 這種情況, 是存在瓶頸的, 需要適當增加快取總量.
Read hit 表示快取命中率 100%, 這個數值是比較理想的, 一般情況下, 都應該大於 99.98%.

Pages
Free 2 %Total: 0.39
Data 499 97.46 %Drty: 0.00
Misc 11 2.15
Latched 0 0.00

innodb的儲存是按頁分的, 每頁的容量預設是 16K. (詳見 http://www.mysqlperformanceblog.com/2006/06/04/innodb-page-size/)

這裡的,Free指的是快取中的總頁數, 剩餘的頁, 佔總的 0.39%.
Data是指快取中, 儲存索引資料的頁的數量.其中, 最後一項 %Dtry 表示髒資料的百分比.所謂的髒資料是指, 對快取資料更新後, 沒有同步到硬碟的資料.
misc 和 latched 就是之前說的其他資訊的一些快取.

Reads 101.06M 8.5/s
From file 373 0.0/s 0.00
Ahead Rnd 19 0.0/s
Ahead Sql 13 0.0/s

Reads代表從快取裡, 總共讀取了多少M的資料.
From file, 表示從硬碟檔案中讀取到快取裡的頁數量.
Ahead Rnd, 表示隨機預讀的次數.
Ahead Sql, 表示全表掃描時, sql預讀的次數.

Writes 860.88k 0.1/s
Flushes 254.62k 0.0/s
Wait Free 0 0/s

Writes , 表示寫入快取的總大小.
Flushes , 表示快取資料更新到硬碟的大小.
Waint Free, 表示, 等待可寫入資料的頁的次數.
這裡為什麼會等待, 是因為, 資料寫入到快取頁時, 必須保證, 這個頁被建立好, 或者這個頁之前的資料已經被同步到硬碟上.

Waits 424 0.0/s
Current 0
Time acquiring
Total 254266 ms
Average 599 ms
Max 39559 ms

Waits , 表示執行執行緒等待鎖的釋放的次數.
Current, 表示當前所有的執行執行緒, 正在等待鎖的數量.
Time acquiring 裡的 Total , 指的是, 等待鎖所消耗的總時間.
Average, 是指, 平均消耗的時間.
Max, 是指, 單次等待鎖, 所消耗最多的時間.

Data
Reads 502 0.0/s
Writes 344.09k 0.0/s
fsync 158.03k 0.0/s
Pending
Reads 0
Writes 0
fsync 0

Data裡的Reads, 表示資料讀取的次數.
Writes, 表示資料寫入的資料量大小.
fsync, 表示快取同步到硬碟的資料量大小.

Pending裡的Reads, Writes, fsync , 表示當前進行讀寫, 同步的次數.

Pages
Created 699 0.0/s
Read 523 0.0/s
Written 254.62k 0.0/s

Pages 裡的created, 表示, 總共建立過 699 個頁.
Read, 表示被讀取的頁的數量.
Written, 表示寫入到頁裡的,總大小.

Rows
Deleted 4.59k 0.0/s
Inserted 74.16k 0.0/s
Read 94.67M 8.0/s
Updated 40.61k 0.0/s

Rows裡的四個操作,分別代表刪除, 插入, 查詢, 更新的資料量大小.

效能關注點分析
首先是Usage, 如果佔比達 90 – 95%以上, 可能需要增加預設快取大小.
調整的引數是 innodb_buffer_pool_size

其次是 Read Hit, 即快取命中率, 如果該值遠遠小於100%, 就要調查快取的有效性了.
比如, 快取寫次數是否大於查詢次數. (Buffer裡的reads和writes)

最後,需要關注的是, 資料的讀寫比例. 這裡有個要注意的地方是, mysql如果啟動到現在不到24小時或一個較長的執行週期, 這個讀寫比例值可能是不準的.

一般的應用,我感覺讀寫比例在 8/2 差不多. 如果讀遠遠大於寫, 那麼你可以測下 MyISAM 引擎的效能, 看看是否適合你.