mysqlreport工具

进行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_子报告显示没有异常，但是时常地检查该部分报告是很有必要的。