mysqlReport 详细解析

myslqReport的安装

mysqlReport 的安装需要在linux环境中，还需要安装perl的环境和perl的两个包，详细步骤如下：

因为我是在Windows环境下，先试着安装了虚拟机，后来发现虚拟机太麻烦了，最后采用了docker环境。

首先下载docker的桌面环境–》 docker安装

安装好docker先现在一个centos镜像，在centos环境下mysqlReport比较好安装。

docker pull centos

然后运行centos镜像

sudo docker run --name test -p 8011:8011 -it  -d -v E:/data:/data/ centos

进入容器内容

docker exec -it test /bin/bash

mysqlreport的运行需要用到票perl的两个包，所以首先更新yum ：

yum update

然后安装perl

yum install perl

然后安装pler的两个包

yum -y install perl-DBIyum -y install perl-DBD-MySQL

最后将mysqlreport的压缩包传入运行的环境内，解压后运行即可附上下载链接 mysqlReport

mysqlreport命令解析：

./mysqlreport --user=root --password=jzyl_123 --port 3306 --host=127.0.0.1  --outfile=/data/log.xt

这里注意一下127.0.0.1 这种端口是访问不到自己的宿主机的，需要替换成iPV4的端口号。

命令参数

--user               # 指定连接数据库的用户--password           #指定连接数据库的密码--port               #指定端口--host               #指定主机--sokcet             #指定socket文件--flush-status       #显示完报告后，执行"FLUSH STATUS"语句--outfile            #将报告输出至某个文件中

mysqlReport

MySQL 5.7.22-log         uptime 5 22:14:49      Thu Dec  2 06:00:08 2021__ Key _________________________________________________________________
Buffer used     5.00k of   8.00M  %Used:   0.06Current       1.46M            %Usage:  18.30
Write hit       0.00%
Read hit       85.29%__ Questions ___________________________________________________________
Total           1.28k     0.0/sCom_            894     0.0/s  %Total:  69.63DMS             376     0.0/s           29.28COM_QUIT         13     0.0/s            1.01+Unknown          1     0.0/s            0.08
Slow 1 s           13     0.0/s            1.01  %DMS:   3.46  Log:
DMS               376     0.0/s           29.28SELECT          376     0.0/s           29.28        100.00REPLACE           0       0/s            0.00          0.00INSERT            0       0/s            0.00          0.00DELETE            0       0/s            0.00          0.00UPDATE            0       0/s            0.00          0.00
Com_              894     0.0/s           69.63show_status     287     0.0/s           22.35change_db       280     0.0/s           21.81set_option      113     0.0/s            8.80__ SELECT and Sort _____________________________________________________
Scan            1.04k     0.0/s %SELECT: 277.13
Range               2     0.0/s            0.53
Full join           0       0/s            0.00
Range check         0       0/s            0.00
Full rng join       0       0/s            0.00
Sort scan         283     0.0/s
Sort range          0       0/s
Sort mrg pass      66     0.0/s__ Query Cache _________________________________________________________
Memory usage   16.31k of   1.00M  %Used:   1.59
Block Fragmnt 100.00%
Hits                0       0/s
Inserts             1     0.0/s
Insrt:Prune       1:1       0/s
Hit:Insert     0.00:1__ Table Locks _________________________________________________________
Waited              0       0/s  %Total:   0.00
Immediate         377     0.0/s__ Tables ______________________________________________________________
Open              645 of 2000    %Cache:  32.25
Opened          1.28k     0.0/s__ Connections _________________________________________________________
Max used            3 of  151      %Max:   1.99
Total              16     0.0/s__ Created Temp ________________________________________________________
Disk table        212     0.0/s
Table           1.37k     0.0/s    Size:  16.0M
File               60     0.0/s__ Threads _____________________________________________________________
Running             1 of    1
Cached              2 of   10      %Hit:  81.25
Created             3     0.0/s
Slow                0       0/s__ Aborted _____________________________________________________________
Clients             2     0.0/s
Connects            0       0/s__ Bytes _______________________________________________________________
Sent           35.10M    68.5/s
Received      218.74k     0.4/s__ InnoDB Buffer Pool __________________________________________________
Usage         532.27M of   3.00G  %Used:  17.33
Read hit       99.86%
PagesFree        162.54k            %Total:  82.67Data         32.52k                     16.54 %Drty:   0.00Misc           1542                      0.78Latched                                  0.00
Reads          18.48M    36.1/sFrom file    26.26k     0.1/s            0.14Ahead Rnd         0       0/sAhead Sql                 0/s
Writes          1.36M     2.7/s
Flushes         8.15k     0.0/s
Wait Free           0       0/s__ InnoDB Lock _________________________________________________________
Waits               0       0/s
Current             0
Time acquiringTotal             0 msAverage           0 msMax               0 ms__ InnoDB Data, Pages, Rows ____________________________________________
DataReads        29.73k     0.1/sWrites       13.10k     0.0/sfsync         2.55k     0.0/sPendingReads           0Writes          0fsync           0PagesCreated       2.95k     0.0/sRead         29.57k     0.1/sWritten      10.44k     0.0/sRowsDeleted           0       0/sInserted    918.72k     1.8/sRead         10.52M    20.5/sUpdated           0       0/s

mysqlReport 详解

基本信息

MySQL 5.7.22-log         uptime 5 22:14:49      Thu Dec  2 06:00:08 2021

mysql当前的版本，运行的时间，以及当前系统时间。

MySQL服务器版本信息表明MySQL服务器包含和不包含哪些特点。 MySQL服务器运行时间表明报告价值的代表性。

服务器运行时间对于评估报告是很重要的，因为如果服务器不运行几个小时的话，输出报告有可能存在曲解和误导性。有时甚至运行几个小时时间都是不够的，比如，MySQL服务器运行了午夜的6个小时几乎没有业务访问过。最理想的情况是，MySQL服务器运行一天之后再运行mysqlreport来输出报告，这样报告的代表价值要比系统刚运行时要好的多。

在性能场景的运行周期前启动mysql，在性能场景结束后生成mysqlreport会比较有用。比如此例中，场景运行了1小时后执行了mysqlreport。

索引报表

__ Key _________________________________________________________________
Buffer used     5.00k of   8.00M  %Used:   0.06Current       1.46M            %Usage:  18.30
Write hit       0.00%
Read hit       85.29%

本部分仅能显示用于MyISAM表的共享索引缓存，其他的缓存并没有显示。
这个地方出了问题需要修改 key_buffer_size 这个数值，注意这个参数是MyISAM表调整的参数
InnoDB调整的参数是innodb_pool_buffer_size

Buffer used     5.00k of   8.00M  %Used:   0.06

说明mysql当前索引缓冲区的使用率，如果过高，则需要调整key_buffer_size的大小了。write hit及read hit分别说明了写索引和读索引的效率。 key_buffer_size 对MyISAM引擎的性能有很大的影响。不能表明是否MySQL服务器索引是否良好，但是能够指示shared key buffer（共享索引缓存）是否被充分利用。本部分仅能显示用于MyISAM表的共享索引缓存，其他的缓存并没有显示。

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%。

请注意，这里所指的 Key Buffer 是指MyISAM Storage Engine 所使用的 Shared Key Buffer，InnoDB 所使用的 Key Buffer 并不包含在内。 MySQL Server 的 Buffer 大略可分为二种：

Global Buffer：由所有 Client 所共享的 Buffer keybuffer innodbbufferpool innodblogbuffer innodbadditionalmempool net_buffer …等等
Thread Buffer：个别的 Connection 所需占用的 Buffer 例如： sortbuffer myisamsortbuffer readbuffer joinbuffer readrnd_buffer …等等。

计算 Server 至少需使用的总内存数量的方式为：

minmemoryneeded = globalbuffer + (threadbuffers * max_connection)

关于 MySQL 的 Cache 机制有一点需要特别注意，MyISAM Storage Engine 将每个 table 分成三个档案储存在硬盘之中，例如若有一个数据表的名称为 example，那么就会在硬盘上发现 example.FRM, example.MYD,example.MYI 等三个档案。这三个档案所储存的数据如下：

FRM： 储存这个数据表的结构
MYD： Row Data，也就是你存在 example 数据表里的数据
MYI： 此数据表的索引接下来是重点： 当MySQL要Cache某个资料表时，MySQL只会Cache索引,也就是MYI档案，而Row Data(.MYD)则是交由操作系统来负责 Cache。

到底 Key Buffer 要设定多少才够呢？如前所述，MySQL只会Cache 索引(.MYI)，因此只要将数据库中所有的 MYI档案加总起来，你就会知道大概要设为多少。

  Current       1.46M            %Usage:  18.30

这一行指示MySQL在生成报告时占用索引缓存的情况（4.1.2和以后的版本有效，因为Keyblocksunused是在4.1.2以后才增加的。）。如果前一行表示是一个高水位指示，那么这一行的占用量应该是小于或等于上一行的高水位。有时也会高于高水位指示，这是不是MySQL的Bug目前还不得而知。不管怎样，这一行和前一行的结果能够很好地指示keybuffersize的参数设置的是不是足够大。在本例子中，MySQL服务器状态就不太好，占用了8M，是索引缓存的100%，已经是全部的空间了。

从以上两个数据就可以看到的是，mysql每一次分配的key buffer很大，每次6.54M，整个key buffer占用已经达到100%了，所以还是要增加key buffer size才行。

Write hit       0.00%

索引（keys）是使用固有RAM分区的。这一行，Write hit，显示了索引写入的效率（这是个百分比比率值，分子是索引写入硬盘的量，分母是索引写入缓存的量）。索引写入命中率没有一个标准值。索引写入命中率依赖于MySQL服务器基本执行的是哪种语句。如果MySQL主要执行的是updates或者inserts，那么索引写入命中率可能接近0%是可接受的；

如果MySQL主要执行的是selects，那么索引写入命中率可能90%或更多是可接受的。一个负数百分比表示MySQL写入索引到硬盘多于写入缓存，这样通常会很慢、不合理的、不可接受的。最好描述索引写入命中率的方法，就是需要你知道MySQL服务器主要执行哪些语句，DMS报告（Lines 17-22）能够帮助解决这一问题。结合Questions部分的DMS里insert的数据量，可知，在这个场景执行的过程中，主要是insert语句，所以这里的索引写入命中率接近0%的。

计算公式：Write hit = (1 - MySQL将索引写入硬盘的次数 / MySQL将索引写入RAM的次数） * 100%

Read hit       85.29%

比索引写入命中率更重要的是索引读取命中率（key read hit）。

这一行描述了索引读取的效率（这是个百分比比率值，分子是索引读取硬盘的量，分母是索引读取缓存的量）。索引读取命中率应该低于99%。过低的百分比表明这会是一个问题。一个低索引命中百分比通常可能是索引空间太小了。索引空间是为了避免MySQL装载过多的索引到内存中，当这种情况发生时，MySQL会恢复从硬盘读取索引，这就会使得硬盘相当慢而且会使索引无效。通常来讲，开始运行MySQL的前1-2个小时，这一行的值会低于99%，经过1-2个小时以后，取值就会接近99%。

计算公式：Read hit = (1 - MySQL从硬盘读取索引的次数 / MySQL从RAM读取索引的次数） * 100%

Key_buffer_UsageRatio = (1 - Key_blocks_used/(Key_blocks_used + Key_blocks_unused)) * 100%
Key_Buffer_Read_HitRatio = (1 - Key_reads/Key_read_requests) * 100%
Key_Buffer_Write_HitRatio = (1 - Key_writes/Key_Write_requests) * 100%

操作报表

__ Questions ___________________________________________________________
Total           1.28k     0.0/sCom_            894     0.0/s  %Total:  69.63DMS             376     0.0/s           29.28COM_QUIT         13     0.0/s            1.01+Unknown          1     0.0/s            0.08
Slow 1 s           13     0.0/s            1.01  %DMS:   3.46  Log:
DMS               376     0.0/s           29.28SELECT          376     0.0/s           29.28        100.00REPLACE           0       0/s            0.00          0.00INSERT            0       0/s            0.00          0.00DELETE            0       0/s            0.00          0.00UPDATE            0       0/s            0.00          0.00
Com_              894     0.0/s           69.63show_status     287     0.0/s           22.35change_db       280     0.0/s           21.81set_option      113     0.0/s            8.80

__ Questions ___________________________________________________________
Total           1.28k     0.0/s

操作报表的第一行表示了MySQL回应了所有问题的总数和更新时间内的平均回应率。从数据可以看到，每秒mysql的操作是1.28k次（QPS），但是有多少完成了，就要看下面的几行数据了。（这里需要说明的是，“Questions（操作）”是被响应的，而“（Queries查询）”是被执行的。mysqlreport可以分辨出“操作”和查询，特别是在“操作数报告”中。“操作”是每个和各种对MySQL服务器的请求，这包含了SQL查询和MySQL特定的命令和协议通信，查询是仅包含SQL查询：SELECT, UPDATE等）

  Com_            894     0.0/s  %Total:  69.63DMS             376     0.0/s           29.28COM_QUIT         13     0.0/s            1.01+Unknown          1     0.0/s            0.08

所有的“操作”可分为5类：数据操作语句（DMS）、查询缓存命中率（QC Hits）、COMQUIT、其他通信命令和未知。这5个分类是动态显示的。mysqlreport按照他们的总次数降序排列。这个子报告能够明显的表示出MySQL在忙着干什么。理想情况下，MySQL应该忙于DMS 或者QC Hits，因为这些行为时真正完成某些事情的。

COMQUIT，Com和Unknown类别是必要的，但是处于次要地位。在进一步解释每一类之前，需要说明的是这部分子报告第三列表明该列值占总“操作”请求数的百分比，“操作”部分的其他子报告也是如此。在例子中，DMS数占总操作数的82.84%是正常示数。

Data manipulation statements（DMS）包括SELECT，INSERT，REPLACE，UPDATE和DELETE。基本上，DMS是MySQL数据库干的最有用的，因此，DMS应该是MySQL做的最多的。DMS子报告会详细显示。

QC Hits（Query Cache Hits）是MySQL查询执行过程中，通过查询缓存补偿，而不是实际执行的操作数。具有一个较高的QC Hits数是令人期待的，因为QC的返回是非常快的。但是，完成有效地QC缓存是非常困难的。这在后面的Query Cache Report中的Insrt:Prune和Hit:Insert部分将深入解释。

在例子中，QC Hits是没有显示的，说明在这个report期间没有select语句。 COMQUIT 是个可以忽略的无关紧要的参数，它包含到报告中为了保证完整性。 Com_ 表示MySQL处理的各种命令，通常都是协议相关的。理想情况下，在这个指标应当比较低，因为当比较高时，说明MySQL忙而无用。该分类参数过高，则表示一些怪异的问题，后面在Com_将详细讨论。 Unknown 是一个推测的目录。理想情况下，前四部分的总和应该是等于全部“操作”数量，但通常不相等。这是因为存在一些MySQL的操作，增加了操作计数器，但是并没有表现在单独的指标上。这一行会动态显示为"+Unknown"或者"-Unknown"。"+Unknown"表示存在更多的操作数，比mysqlreport计算的多；"-Unknown"表示mysqlreport计算的数比所有的统计数少。

Slow 1 s          515     0.0/s            0.00  %DMS:   0.00  Log:

指示了MySQL执行的慢查询数目有多少。影响“Slow”指标的系统参数 longquerytime，这一参数默认值为10s。很多人认为10s是在数据库时间中时一个恒定值，longquerytime 最好设置为1秒或者毫秒级单位（毫秒设置在MySQL的新版本中支持） longquerytime，这一参数值只有慢查询之后才会显现出来。在mysqlreport v3.5以后，该参数支持：秒、毫秒、微妙。在某些情况下，该参数由于显示宽度8个字母的限制。例如，longquerytime 的参数值’999.999 ms’截断成’999.999 '，'10.000100 s’截断成’10.0001 '。理想情况下，慢查询的统计应该为0，但是通常也会有一些慢查询的存在。一般来说，慢查询的比率（第三列）占整个操作数的0.05或更低。当有很多慢查询（第一列），这是的比率值就会显示出问题。这一行还增加了一列：DMS操作数百分比。对于慢查询，0是最好的，这一列在DMS子报告中更加有用。最后一列，Log，表示慢查询日志功能开启还是关闭（通过设置logslowqueries参数）。慢查询日志通常是打开的。

DMS               376     0.0/s           29.28SELECT          376     0.0/s           29.28        100.00REPLACE           0       0/s            0.00          0.00INSERT            0       0/s            0.00          0.00DELETE            0       0/s            0.00          0.00UPDATE            0       0/s            0.00          0.00

DMS子报告，和DTQ子报告一样，第一列是按照降序排列的,第二列是按每秒计算的结果，第三列表明该列值占总数的百分比。表示了前文所提到数据操作数（SELECT、INSERT等）。第一行显示的和DTQ报告中的显示一样的。这一子报告显示MySQL数据库是哪一种类的数据库：是查询负荷高、还是插入负荷高、还是其他的。MySQL服务器都是倾向于查询负荷高（SELECT heavy）。

了解是哪种类型的MySQL数据库有利于理解其他的报告值。例如，一个插入负荷高的服务器，其写入率会接近为1.0，这种类型的数据库锁表报告值也会偏高，这类数据库适合采用InnoDB类型表；一个查询负荷高的数据库，就会表现出读取率为1和一个较低的表锁值，这种类型的数据库需要采用查询缓存，适合于采用MyISAM表。在这个例子中，服务器是一个查询高的数据库。很明显，这个数据库面向查询事务。知道数据库类型就有利于数据库参数的优化。

Com_              894     0.0/s           69.63show_status     287     0.0/s           22.35change_db       280     0.0/s           21.81set_option      113     0.0/s            8.80

Com子报告和其他子报告一样分类排序。这部分子报告的内容不同于服务器到服务器命令，因为每一行指示的Com指标都是表现的MySQL协议的命令，你可以参考MySQL的帮助文档理解这部分概念。大部分的条目名称都是很直观的，比如Comchangedb。这部分指标当DTQ子报告中的Com最高时才起作用，此时表明MySQL正忙于“程序事务”而不是SQL查询事务。举个例子，一台服务器的Comrollback指标很高。rollback发生在事务处理失败的时候。服务器的每一次事务处理都失败，很显然，服务器是有问题的。在没有mysqlreport的情况下，很明显是不可能分辨出服务器的这些问题的。大部分服务器，Com_子报告显示没有异常，但是时常地检查该部分报告是很有必要的。

查询和排序报表

__ SELECT and Sort _____________________________________________________
Scan            1.04k     0.0/s %SELECT: 277.13
Range               2     0.0/s            0.53
Full join           0       0/s            0.00
Range check         0       0/s            0.00
Full rng join       0       0/s            0.00
Sort scan         283     0.0/s
Sort range          0       0/s
Sort mrg pass      66     0.0/s

Scan 指的是有多少 SELECT statements 造成 MySQL 需要进行 Full Table Scan。Full Join 的意思与 Scan 差不多，但它是适用在多个 Tables 相互Join 在一起的情况。这二种情况的执行效能都非常的差，因此原则上你会希望这两个数值越低越好。但这也不是绝对的，仍然要考虑实际的情况，例如虽然Server 有很高比例的 Scan，但若这些 Scan 都是针对一些只有几十笔数据的 table，那么相对而言它依然是十分有效率的；但反之，若这些 Scan 是针对具有上百万笔数据的 table，那么就会严重影响系统效能。

查询缓存报表

__ Query Cache _________________________________________________________
Memory usage   16.35k of   1.00M  %Used:   1.60
Block Fragmnt 100.00%
Hits                0       0/s
Inserts             1     0.0/s
Insrt:Prune       1:1       0/s
Hit:Insert     0.00:1

查询缓存的目的很简单，将select查询的结果缓存在内存中，以供下次直接获取。

在这个场景中缓存查询是没有开启的。

query_cache_size = 1048576
query_cache_type = OFF
query_cache_limit = 1048576

在查询为主的数据库的由要开启缓存查询，并且要配置合理的查询缓存大小。

但是，查询缓存有一个需要注意的问题，那就是缓存过期策略，MySQL采用的机制是，当一个数据表有更新操作（比如update或者insert）后，那么涉及这个表的所有查询缓存都会失效。这的确令人比较沮丧，但是MySQL这样做是不希望引入新的开销而自找麻烦，所以“宁可错杀一千，不可放过一个”。这样一来，对于select和update混合的应用来说，查询缓存反而可能会添乱。

如果你的应用中对于密集select的数据表很少更新，很适合于使用查询缓存。Block Fragmnt这个数值越高表示 Query Cache 的碎片状况越严重，通常它会界于 10%~20% 之间。在此范例中 Block Fragmnt 为 100%，这是因为缓存根本没有开启。如果开启缓存后此项值还是高，可以调整 querycacheminresunit 的值来降低Block Fragmnt。

Hits 是这三个数值中最重要的一项，因为它指出有多少 SELECT statements 是可直接从 Query Cache 里面取得所需的信息，此数值越高就越好。Inserts 和 Prunes 最好是从比值来观察比较容易理解。虽然 Prunes 的值偏高可能代表着Query Cache 设得不够大，但并不一定是如此。在上例中只有 55% 的 Query Cache 被使用，有着相对而言算低的fragmentation 值，但 Prunes 值偏高，Prunes 的值(16/s)是 QC Hits 的两倍。可以想象这台Server 的 Query Cache 是一颗苹果树，它的树枝被剪去的速度比你采收苹果的速度还快。

Insert 与 Prune 的比值可显示 Query Cache 的挥发性。在一个高度稳定的 Query Cache 中，Insert 的值应该要高于 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 的数据，

你可以使用 SQLNOCACHE 来明确的告诉 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 或许可以解决此问题。

query_cache_min_res_unit 是一个可用于优化查询的变量，具体取决于您可能正在使用的大量结果集。根据定义，该值是MySQL为存储查询而分配的最小内存量。您希望此值大致为平均查询大小。每个数据库的最小值都不同，具体取决于您使用的集合的大小。

表锁报表

__ Table Locks _________________________________________________________
Waited              0       0/s  %Total:   0.00
Immediate      23.47k     0.0/s

Waited 表示有多少次查询需要等待表锁定；Immediate 表示有多少次查询可以立即获得表锁定，同时后面还有一个比例，表示等待表锁定的查询次数占所有查询次数的百分比，这里是0.00%，非常好，但为什么这么低呢？这需要了解 MyISAM 的表锁定机制。 MyISAM 的表锁定可以允许多个线程同时读取数据，比如 select 查询，它们之间是不需要锁等待的。但是对于更新操作（如update操作），它会排斥对当前表的所有其他查询，包括select查询。除此之外，更新操作有着默认的高优先级，这意味着当表锁释放后，更新操作将先获得锁定，然后才轮到读取操作。也就是说，如果有很多update操作排着长队，那么对当前表的 select 查询必须等到所有的更新都完成之后才能开始。

这个部份包含了两项信息：

第一项是 Waited，代表 MySQL 需要等待以取得 table lock 的次数。
第二项是 Immediate，表示MySQL 不需要等待即可立刻取得 table lock 的次数。

对数据库来说『等待』几乎可以肯定是一件很不好的事情，因此 Waited 的值应该要越小越好。最具有代表性的是第三个字段 (Waited 占所有 table lock 的百分比)，这个数值应该要小于 10%，大于这个值就表示table/query 的索引设计不良或是有过多的 Slow Query。

表信息报表

__ Tables ______________________________________________________________
Open              645 of 2000    %Cache:  32.25
Opened          1.28k     0.0/s

第一是 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 _________________________________________________________
Max used            3 of  151      %Max:   1.99
Total              16     0.0/s

Connections Report 所代表的意义与 Tables Report 相似，请各位以此类推。比较需要注意的是：若你发现 Connections 的使用率接近 100%，也许你会想调大 maxconnections 的值以允许MySQL 的 Client 建立更多连接。然而，这通常是一种错误。常常可以发现很多网络上的数据会教我们要调大 maxconnections，但却从来没有给一个明确的理由。事实上，maxconnections 的默认值(100)，就算是对于负载十分沉重但有良好调校过的 Server 都已十分足够。

MySQL 对于单一连接的数据处理通常只需要零点几秒的时间即可完成，就算是最大只能使用 100 个连接也够让你用上很长一段时间。若是的 Server 有着非常高的最大连接数(max connections)或是单一连接需要很长时间才可完成，那么问题八成不是 maxconnections 的值不够大而是在别的地方，

例如 slow queries、索引设计不良、甚至是过于缓慢的 DNS 解析。在将 max_connections 的值调到 100 以上之前，应该要先确定真的是因为Server 过于忙碌而需要调高此数值，而不是其它地方出了问题。每秒平均连接数有可能会很高，事实上，若这个值很高而且 Server 的运作十分顺畅，那么这通常会是一个好现象，无需担心。大部份 Server 的每秒平均连接数应该都会低于 5/s。

临时表报表

__ Created Temp ________________________________________________________
Disk table        212     0.0/s
Table           1.37k     0.0/s    Size:  16.0M
File               60     0.0/s

或许看到一些explain查询在分析时出现Using temporary的状态，这意味着查询过程中需要创建临时表来存储中间数据，我们需要通过合理的索引来避免它。另一方面，当临时表在所难免时，我们也要尽量减少临时表本身的开销，通过mysqlreport报告中的Created Temp部分，我们可以看到：MySQL可以将临时表创建在磁盘（Disk table）、内存（Table）以及临时文件（File）中，显然，在磁盘上创建临时表的开销最大，所以我们希望MySQL尽量不要在磁盘上创建临时表。在MySQL的配置中，我们可以通过tmptablesize选项来设置用于存储临时表的内存空间大小，一旦这个空间不够用，MySQL将会启用磁盘来保存临时表，你可以根据mysqlreport的统计尽量给临时表设置较大的内存空间。

线程报表

__ Threads _____________________________________________________________  #线程报表
Running             1 of    1
Cached              2 of   10      %Hit:  81.25
Created             3     0.0/s
Slow                0       0/s__ Aborted _____________________________________________________________  #中断报表
Clients             2     0.0/s
Connects            0       0/s__ Bytes _______________________________________________________________  #流量报表
Sent           35.10M    68.5/s
Received      218.74k     0.4/s

MySQL采用多线程来处理并发的连接，通过mysqlreport中的Threads部分，可以看到线程创建的统计结果：

也许你会觉得创建线程的消耗不值一提，但是所谓优化都是在你系统繁忙下的救命稻草。一个比较好的办法是在应用中尽量使用持久连接，这将在一定程度上减少线程的重复创建。另一方面，从上面的Cached=0可以看出，这些线程并没有被复用。在本例中，threadcachesize = 64，只用到了5个线程，并且没有复用（Cached)的。

上面的%HIT需要关注下，每一个连接到 MySQL 的联机都是由不同的 Thread 来处理，当 MySQL 启动时会预先建立一些 Threads 并保留在 Thread Cache 中，如此一来 MySQL 就不用一直忙着建立与删除 Threads。但当每秒最大联机数大于 MySQL 的 Thread Cache 时，MySQL 就会进入Thread Thrash 的状态：它不断地建立新的 Threads 以满足不断增加的联机的需求。当 Thread Thrash 发生时，%Hit 的数值就会降低。在本范例中 %Hit 的值为 96.5%，这是非常好的，因为它表示几乎每一个新进来的联机都不会造成 MySQL 建立新的 Thread。而在本例中，threadcachesize 是88，当前 Running的 threads 也很少，可见并没有太大的压力。

InnoDB缓存池报表

__ InnoDB Buffer Pool __________________________________________________
Usage         111.98M of 127.98M  %Used:  87.50
Read hit       91.82%
PagesFree          1.02k            %Total:  12.50Data          7.13k                     87.05 %Drty:   0.00Misc             37                      0.45Latched                                  0.00
Reads         448.48G   33.8k/sFrom file    36.66G    2.8k/s            8.18Ahead Rnd         0       0/sAhead Sql                 0/s
Writes          7.91G   595.4/s
Flushes       126.26M     9.5/s
Wait Free   301211523    22.7/s

__ InnoDB Buffer Pool __________________________________________________
Usage         111.98M of 127.98M  %Used:  87.50
Read hit       91.82%

Innodbbufferpoolsize定义了InnoDB存储引擎的表数据和索引数据的最大内存缓冲区大小。和 MyISAM 存储引擎不同， MyISAM 的 keybuffersize 只能缓存索引键，而 Innodbbufferpoolsize 却可以缓存数据块和索引键。适当的增加这个参数的大小，可以有效的减少InnoDB类型的表的磁盘I/O。如果你在MySQL中大量使用Innodb类型表，则可以将缓冲池大小设置为物理内存的60%-80%（最好配置成自增长的缓冲池），并持续关注它的使用率。如下Usage 表示, 总的缓存16G中, 当前已占用2.27G, 使用率14.20%，这种情况下完全不用考虑增加innodb缓存池。 Read hit 表示缓存命中率 100%, 这个数值是比较理想的,一般情况下, 都应该大于 99.98%。

可以通过如下命令查询缓存大小

 show global variables like 'innodb_buffer_pool_size';

这部分数据和innodbflushlogattrx_commit参数关系非常大。

innodbflushlogattrx_commit = 1 表示事务提交时立即将事务日志写入磁盘，同时数据和索引也立即更新。这符合事务的持久性原则。

innodbflushlogattrx_commit = 0 表示事务提交时不立即将事务日志写入磁盘，而是每隔1秒写入磁盘文件一次，并且刷新到磁盘，同时更新数据和索引。这样一来，如果mysqld崩溃，那么在内存中事务日志缓冲区最近1秒的数据将会丢失，这些更新将永远无法恢复。

innodbflushlogattrx_commit = 2 表示事务提交时立即写入磁盘文件，但是不立即刷新到磁盘，而是每隔1秒刷新到磁盘一次，同时更新数据和索引。在这种情况下，即使mysqld崩溃后，位于内核缓冲区的事务日志仍然不会丢失，只有当操作系统崩溃的时候才会丢失最后1秒的数据。

显然，将innodbflushlogattrx_commit设置为0可以获得最佳性能，同时它的数据丢失可能性也最大。

PagesFree          1.02k            %Total:  12.50Data          7.13k                     87.05 %Drty:   0.00Misc             37                      0.45Latched                                  0.00

Free: 空闲页，是使用率（%Used）的对立方。
Data: 数据页，列%Dirty，展示已经被修改过，但还没有被刷新到磁盘存储的数据页的比率。
Misc：用于管理分配行锁和自适应哈希索引导致的开销使用的页。
Latched: 目前正在读写、或者因为其他原因无法被刷新的页。

Reads         448.48G   33.8k/sFrom file    36.66G    2.8k/s            8.18Ahead Rnd         0       0/sAhead Sql                 0/s
Writes          7.91G   595.4/s
Flushes       126.26M     9.5/s
Wait Free   301211523    22.7/s

Reads从内存读取的数量, 这个数值可以用来衡量innodb缓冲池的吞吐量,因为几乎所有inondb需要的东西都是在缓冲池里，所以缓冲池的读性能是越快越好。哪怕超过每秒200000次也不是不可能的。

From file: 从磁盘读的数量，越小越好。
Ahead Rnd: 随机读，innodb启动的随机读取数。只有对表的大部分内容进行随机扫描的时候才会出现。
Ahead Sql: 顺序读，只有全表扫描才会出现。
Writes：本行显示写的数量以及读写的比率。如果服务器主要操作是update和insert的话，这个值也会比较高。
Flushes: 缓冲池的页刷新请求数。
Wait Free：一般情况下，innodb缓冲池的写操作是后台运行的。不过，如果出现必须要读写一个页可偏偏没有可用的新页时，（innodb）就只能先等待页的刷新了。这个变量就是这些等待的总数。只要缓冲池的大小设置得当，等待数应该会很小。

Innodb锁报表

__ InnoDB Lock _________________________________________________________
Waits               0       0/s
Current             0
Time acquiringTotal             0 msAverage           0 msMax               0 ms

Waits：等待某行解锁的累积次数，最好为0。
Current：当前正在等待解锁的行个数，最好为0。
Time acquiring：显示了毫秒(ms)级行锁等待数据。分别是总值、平均值和最大值。同样最好是0次。

InnoDB数据、页、行报表

__ InnoDB Data, Pages, Rows ____________________________________________
DataReads        29.73k     0.1/sWrites       13.10k     0.0/sfsync         2.55k     0.0/sPendingReads           0Writes          0fsync           0PagesCreated       2.95k     0.0/sRead         29.57k     0.1/sWritten      10.44k     0.0/sRowsDeleted           0       0/sInserted    918.72k     1.8/sRead         10.52M    20.5/sUpdated           0       0/s

  Reads        50.34G    3.8k/sWrites      150.00M    11.3/sfsync        26.44M     2.0/sPendingReads           0Writes          0fsync           0

这部分报告，一般广泛的用于衡量innodb引擎的吞吐量指标。
Reads/Writes: 指的是整个innodb引擎完成所有的数据读/写次数。
注意：不是整个数据读取字节数或者类型，而是innodb完成的数据读/写次数。

fsync：刷新，innodb从内存写入磁盘的次数。这个值应该会比前两个小。
Pending: 等待，又被分成了三行(108-110)，分别是读、写、刷新的等待次数。

PagesCreated       2.95k     0.0/sRead         29.57k     0.1/sWritten      10.44k     0.0/sRowsDeleted           0       0/sInserted    918.72k     1.8/sRead         10.52M    20.5/sUpdated           0       0/s

包括三种自描述类型：创建、读取、写入，分别用来表示缓冲池中页的创建、读取和写入的数量和速率(即每秒操作数)。