[Admin1]

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 並不是我們最需要關心的問題，但當你解決了所有其他更嚴重的問題之後，它就會是最嚴重的問題。(hread caching really wasn't the worst of our problems. But it became the worst after we had fixed all the bigger ones.)