mysqlreport工具(1)

mysqlreport工具（一） (2012-02-23 15:58:41)
转载▼
标签： 杂谈分类： 技术分享
写在前面
看到微博上有人笑谈，如果你没有一个自己的技术博客，你不敢说你自己是搞过研发的！嗨，俺是一个俗人，想想这个还是随大流吧！
这篇文章主要是参考http://hackmysql.com/mysqlreport上的内容，是我去年遇到一个MySQL问题是苦于没有检测工具，从《高性能MySQL》中了解到的一个工具，比较不错。一直想把这篇文章翻译一下，没有恒心。赶上公司要交流，想到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 4MySQL服务器的首要问题：索引缓存用了多少？如果它并没有被用很多，说明状况比较好，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%。