進行MySQL的配置優化，首先必須找出MySQL的性能瓶頸所在；而SHOW STATUS輸出的報告正是用來計算性能瓶頸的參考數據。mysqlreport不像SHOW STATUS那樣簡單的羅列數據，而是對這些參考數據加以融合計算，整理成一個個優化參考點，然后就可以根據這個優化參考點的值以及該點的衡量標准，進行對應調整。
安裝就不贅述了，很簡單。估計redhat的話直接copy上就能執行。我是在公司內部版本的服務器上運行的，需要再安裝perl-DBI和perl-DBD-MySQL。搞不定，問google吧。
運行輸出報告（我喜歡這種方式）：mysqlreport --user=root --password=root_password --port=3306 --outfile=/data/mysql_data/report/mysqlreport.txt
下面是報告說明（英文參考）http://hackmysql.com/mysqlreportguide
本手冊用於解釋mysqlreport輸出的信息，本手冊幫助理解報告中所有內榮，進而判斷mysql服務器運行的如何？
目前的mysqlreport能夠自動的生成一份完整的分析MySQL狀態數據的報告。完整的報告包含14個部分112行。根據MySQL服務器的配置，一部分的區域並不會生成。例如，如果query caching選項被關閉，那么報告的第4部分Query Cache將不會生成。因此，報告的長度會有所不同。
為了跟好的幫助理解您所看見的報告，手冊將完整的進行信息的說明，每部分都是逐行解釋說明的。
Report Header: Line 1
報告的第一行，報頭，包含三部分信息：MySQL服務器版本信息，MySQL服務器運行時間，服務器當前時間。
MySQL服務器版本信息表明MySQL服務器包含和不包含哪些特點。MySQL服務器運行時間表明報告價值的代表性。服務器運行時間對於評估報告是很重要的，因為如果服務器不運行幾個小時的話，輸出報告有可能存在曲解和誤導性。有時甚至運行幾個小時時間都是不夠的，比如，MySQL服務器運行了午夜的6個小時幾乎沒有業務訪問過。最理想的情況是，MySQL服務器運行一天之后再運行mysqlreport來輸出報告，這樣報告的代表價值要比系統剛運行時要好的多。
在這個例子中，MySQL服務器運行了34分鍾，因此，此報告不具備代表性。
Key Report: Lines 3 - 7
第一主要報告部分是Key report（索引報告），因為MySQL服務器的索引信息是最重要部分。盡管報告不能表明是否MySQL服務器索引是否良好，但是它能夠指示shared key buffer（共享索引緩存）是否被充分利用。本部分僅能顯示用於MyISAM表的共享索引緩存，其他的緩存並沒有顯示。
Buffer used: Line 4
MySQL服務器的首要問題：索引緩存用了多少？如果它並沒有被用很多，說明狀況比較好，MySQL僅僅是在需要時分配了用於索引緩存的系統RAM。也就是說，如果索引緩存設置為512M，那么MySQL不是在系統開始時就分配的512M內存，MySQL僅僅會當需要時才會分配512M那么多！
第四行，Buffer used，顯示的就是MySQL曾經一次分配的最大的數量。實際上，MySQL實際的使用量會少，也有可能多於這個數。MySQL稱之為“高水位（high water mark）”。這一指標通常說明MySQL的配置指標中key_buffer_size是否足夠大。如果報告的此行指示，MySQL已經占用了索引緩存的80%到90%，那么key_buffer_size的參數就應該增大。注意，這一行的指標是不可能超過95%的。考慮到mysqlreport無法計算一些內部數據結構對索引緩存的占用情況，所以，95%通常也就是表示為100%。
在本例子中，MySQL利用了512M緩存的380k空間，所以索引緩存是相當大的，但是下一行卻表示了不一樣的東西。
Current: Line 5
這一行僅當MySQL服務器為version4.1.2和以后的版本才有效，因為Key_blocks_unused是在version4.1.2以后的版本中才增加的。這一行指示MySQL在生成報告時占用索引緩存的情況。如果前一行表示是一個高水位指示，那么這一行的占用量應該是小於或等於上一行的高水位。有時也會高於高水位指示，這是不是MySQL的Bug目前還不得而知。不管怎樣，這一行和前一行的結果能夠很好地指示key_buffer_size的參數設置的是不是足夠大。
在本例子中，MySQL服務器狀態就很好，占用了近60M，是索引緩存的12%，還沒有接近完全的空間。
Write hit: Line 6
索引（keys）是使用固有RAM分區的。他們的效能表現在他們是緩存在能夠快速接入的內存中，而不是接入速度較慢的內存中。但是，MySQL也不可避免的時常讀取和寫入硬盤。
這一行，Write hit，顯示了索引寫入的效率（這是個百分比比率值，分子是索引寫入硬盤的量，分母是索引寫入緩存的量）。索引寫入命中率沒有一個標准值。索引寫入命中率依賴於MySQL服務器基本執行的是哪種語句。如果MySQL主要執行的是updates或者inserts，那么索引寫入命中率可能接近0%是可接受的；如果MySQL主要執行的是selects，那么索引寫入命中率可能90%或更多是可接受的。一個負數百分比表示MySQL寫入索引到硬盤多於寫入緩存，這樣通常會很慢、不合理的、不可接受的。
最好描述索引寫入命中率的方法，就是需要你知道MySQL服務器主要執行哪些語句，DMS報告（Lines 17-22）能夠幫助解決這一問題。
Read hit: Line 7
比索引寫入命中率更重要的是索引讀取命中率（key read hit）。這一行描述了索引讀取的效率（這是個百分比比率值，分子是索引讀取硬盤的量，分母是索引讀取緩存的量）。索引讀取命中率應該低於99%。
過低的百分比表明這會是一個問題。一個低索引命中百分比通常可能是索引空間太小了。索引空間是為了避免MySQL裝載過多的索引到內存中，當這種情況發生時，MySQL會恢復從硬盤讀取索引，這就會使得硬盤相當慢而且會使索引無效。
通常來講，開始運行MySQL的前1-2個小時，這一行的值會低於99%，經過1-2個小時以后，取值就會接近99%。
Questions Report: Lines 9 - 26
第二個主要報告區域，Questions。說他第二重要是因為這部分主要說明MySQL都在忙着干什么，還有MySQL在做事時有多忙。“操作”包含SQL語句和MySQL協議通信。最普遍關心的問題是MySQL運行過程中每秒運行多少SQL語句，但是這種考慮問題方法是過於武斷地的。這部分報告考慮的更加全面。
Total: Line 10
第一行表示了MySQL回應了所有問題的總數和更新時間內的平均回應率。這一比率通常會讓人得出結論“我的MySQL服務器平均每秒鍾100次處理數”。但是，真正的問題是，在這100個處理數中，有多少是真正完成的呢？后面幾行回答了這一問題。
（這里需要說明的是，“Questions（操作）”是被響應的，而“（Queries查詢）”是被執行的。mysqlreport可以分辨出“操作”和查詢，特別是在“操作數報告”中。“操作”是每個和各種對MySQL服務器的請求，這包含了SQL查詢和MySQL特定的命令和協議通信，查詢是僅包含SQL查詢：SELECT, UPDATE等）
Distribution of Total Queries (DTQ): Lines 11 - 15
所有的“操作”可分為5類：數據操作語句（DMS）、查詢緩存命中率（QC Hits）、COM_QUIT、其他通信命令和未知。這5個分類是從11至15行動態顯示的。mysqlreport按照他們的總次數降序排列。這個子報告能夠明顯的表示出MySQL在忙着干什么。理想情況下，MySQL應該忙於DMS 或者QC Hits，因為這些行為時真正完成某些事情的。COM_QUIT，Com_和Unknown類別是必要的，但是處於次要地位。
在進一步解釋每一類之前，需要說明的是這部分子報告第三列表明該列值占總“操作”請求數的百分比，“操作”部分的其他子報告也是如此。在例子中，DMS數占總操作數的82.84%是正常示數。
Data manipulation statements（DMS）（Line 11）包括SELECT，INSERT，REPLACE，UPDATE和DELETE。基本上，DMS是MySQL數據庫干的最有用的，因此，DMS應該是MySQL做的最多的。DMS子報告會在行17-22之間詳細顯示。
QC Hits（Line 12）是MySQL查詢執行過程中，通過查詢緩存補償，而不是實際執行的操作數。具有一個較高的QC Hits數是令人期待的，因為QC的返回是非常快的。但是，完成有效地QC緩存是非常困難的。這在后面的Query Cache Report中的Insrt:Prune和Hit:Insert部分將深入解釋。
在例子中，QC Hits在所有的“問題”中占16.91%，這一指標已是相當不錯的。但是，不要被這個誤導，“Query Cache Report”描述了更復雜的事情。盡管QC Hits貌似很不錯，但是服務器的查詢緩存並不像想象中那么好。
COM_QUIT （Line 13）是個可以忽略的無關緊要的參數，它包含到報告中為了保證完整性。具體內容可參考“COM_QUIT and Questions”的描述文章（地址：http://hackmysql.com/com_quit）
Com_ （Line 14）表示MySQL處理的各種命令，通常都是協議相關的。理想情況下，在這個指標應當比較低，因為當比較高時，說明MySQL忙而無用。該分類參數過高，則表示一些怪異的問題，后面在Com_將詳細討論。
Unknown （Line 15）是一個推測的目錄。理想情況下，前四部分的總和應該是等於全部“操作”數量，但通常不相等。這是因為存在一些MySQL的操作，增加了操作計數器，但是並沒有表現在單獨的指標上。
這一行會動態顯示為"+Unknown"或者"-Unknown"。"+Unknown"表示存在更多的操作數，比mysqlreport計算的多；"-Unknown"表示mysqlreport計算的數比所有的統計數少。
This category can vary greatly. On some servers it is near the top, but on most it is at the very bottom. It is better for it to be at the very bottom. Eventually, the nature of these unknowns will be discovered and mysqlreport will account for them correctly.
Slow: Line 16
第16行是非常重要的：他指示了MySQL執行的慢查詢數目有多少。影響“Slow”指標的系統參數long_query_time，這一參數默認值為10s。很多人認為10s是在數據庫時間中時一個恆定值，long_query_time最好設置為1或者毫秒級單位（毫秒設置在MySQL的新版本中支持）
long_query_time，這一參數值只有慢查詢之后才會顯現出來。在mysqlreport v3.5以后，該參數支持：秒、毫秒、微妙。在某些情況下，該參數由於顯示寬度8個字母的限制。例如，long_query_time的參數值'999.999 ms'截斷成'999.999 '，'10.000100 s'截斷成'10.0001 '。
理想情況下，慢查詢的統計應該為0，但是通常也會有一些慢查詢的存在。一般來說，慢查詢的比率（第三列）占整個操作數的0.05或更低。當有很多慢查詢（第一列），這是的比率值就會顯示出問題。這一行還增加了一列：DMS操作數百分比。對於慢查詢，0是最好的，這一列在DMS子報告中更加有用。
最后一列，Log，表示慢查詢日志功能開啟還是關閉（通過設置log_slow_queries參數）。慢查詢日志通常是打開的。
DMS: Lines 17 - 22
DMS子報告，和DTQ子報告一樣，第一列是按照降序排列的。該部分從17到22，共6行，表示了前文所提到數據操作數（SELECT、INSERT等）。第一行顯示的和DTQ報告中（第11行）的顯示一樣的。
這一子報告顯示MySQL數據庫是哪一種類的數據庫：是查詢負荷高、還是插入負荷高、還是其他的。MySQL服務器都是傾向於查詢負荷高（SELECT heavy）。了解是哪種類型的MySQL數據庫有利於理解其他的報告值。例如，一個插入負荷高的服務器，其寫入率會接近為1.0，這種類型的數據庫鎖表報告值也會偏高，這類數據合適與采用InnoDB類型表；一個查詢負荷高的數據庫，就會表現出讀取率為1和一個較低的表鎖值，這種類型的數據庫需要采用查詢緩存，適合於采用MyISAM表。
（原文是“ A SELECT heavy server had better have a read ratio of zero and a very low table lock values.”，我覺得是筆誤吧）
在這個例子中，服務器是一個查詢符合高的數據庫。很明顯，這個數據庫面向查詢事務。知道數據庫類型就有利於數據庫參數的優化。
Com_: Lines 23 - (26)
Com_子報告和其他子報告一樣分類排序。這部分子報告的內容不同於服務器到服務器命令，因為每一行指示的Com_指標都是表現的MySQL協議的命令，你可以參考MySQL的幫助文檔理解這部分概念（網址為：http://forge.mysql.com/wiki/MySQL_Internals）。大部分的條目名稱都是很直觀的，比如Com_change_db。
這部分指標當DTQ子報告中的Com_最高時才起作用，此時表明MySQL正忙於“程序事務”而不是SQL查詢事務。舉個例子，一台服務器的Com_rollback指標很高。rollback發生在事務處理失敗的時候。服務器的每一次事務處理都失敗，很顯然，服務器是有問題的。在沒有mysqlreport的情況下，很明顯是不可能分辨出服務器的這些問題的。
大部分服務器，Com_子報告顯示沒有異常，但是時常地檢查該部分報告是很有必要的。