25、mysqlreport(my.cnf)调优工具

25.1、mysqlreport介绍：

mysqlreport以很友好的方式显示 MySQL状态变。事实上，它几乎报告了所有的状态。不像 SHOW STATUS 只是在显示

了100多个状态值，mysqlreport 则以人性化的方式阐释和格式化了这些状态值，大大增加了其可读性。

25.2、安装mysqlreport：

MySQLReport 是用perl语言编写，所以想要运行它首先需要安装perl环境；

它还要与MySQL数据库连接，所以还需要安装数据库接口DBI和数据库驱动DBD-MySQL 。

[root@backup ~]# yum install -y perl

[root@backup ~]#yum -y install perl-DBI #安装数据库接口DBI；

[root@backup ~]#yum -y install perl-DBD-MySQL #安装数据库驱动DBD-MySQL;

[root@backup ~]#yum -y install mysqlreport #安装mysqlreport；

[root@backup ~]#rpm -qa mysqlreport perl-DBD-MySQL perl-DBI perl

mysqlreport-3.5-4.el6.noarch

perl-DBI-1.609-4.el6.x86_64

perl-DBD-MySQL-4.013-3.el6.x86_64

perl-5.10.1-144.el6.x86_64

25.3、mysqlreport常用命令说明：

[root@backup ~]#mysqlreport --help

   --user #连接MySQL的用户名；

   --password #连接MySQL用户的密码；

   --host #连接MySQL远程服务器的ip地址；

   --port #连接MySQL的端口号；

   --socket #连接MySQL的socket；

   --no-mycnf #不读取〜/ .my.cnf；

   --infile FILE #从文件中读取而不是从MySQL(show status)读取状态值；

   --outfile FILE #在屏幕上输出报告后将报告写入FILE;

   --email ADDRESS #在屏幕上输出完成后将结果发送到指定的电子邮件地址（在Windows上不起作用）；

   --flush-status #显示完报告后执行flush-status命令，如果没有权限，则 DBD::mysql 会显示返回值；

   --help #打印帮助；

   --debug #打印调试信息；

有关更多信息，请访问http://hackmysql.com/mysqlreport。

25.4、输出结果说明：

[root@backup tmp]#mysqlreport --user root --password 123456 --socket /data/3306/mysql.sock

Use of uninitialized value $is in multiplication (*) at /usr/bin/mysqlreport line 829.

Use of uninitialized value in formline at /usr/bin/mysqlreport line 1227.

Use of uninitialized value in formline at /usr/bin/mysqlreport line 1235.

# 数据库版本 # 数据库启动的时间（这里是40分钟）

MySQL 5.5.32 uptime 0 0:40:3 Wed Feb 4 06:52:23 2015

# MyISAM 索引信息，本质来讲，索引最好是都在内存中

__ Key _________________________________________________________________

#在my.cnf文件中的key_buffer_size定义索引缓存的大小, 缺省是8M, 可考虑设置为512M

Buffer used 0 of 8.00M %Used: 0.00

# 当Usage到达80或90%，就表示负荷过大，要考虑加大缓存的大小

Current 1.46M %Usage: 18.24

# 写命中。写索引的效率（即写入内存与写入硬盘的比例）

Write hit 0.00%

# 读命中。这个非常重要，表示索引信息读内存的命中率，越高越好

Read hit 0.00%

__ Questions ___________________________________________________________

# MySQL自启动以来一共处理了多少个请求，这里是8540个请求，平均每秒是3.6个

Total 8.54k 3.6/s

Com_ 10.60k 4.4/s %Total: 124.20

-Unknown 10.20k 4.2/s 119.51

# 数据操作语句

DMS 8.11k 3.4/s 94.94

COM_QUIT 32 0.0/s 0.37

# 慢查询日志，查询超过10s是慢查询日志，一般设置为1s

Slow 10 s 0 0/s 0.00 %DMS: 0.00 Log:

# 数据操作语句的详细信息，可以得知读写比等信息

DMS 8.11k 3.4/s 94.94

# 查询4980次，每秒2.1次

SELECT 4.98k 2.1/s 58.35 61.46

# 更新1710次，每秒0.7次

UPDATE 1.71k 0.7/s 20.05 21.12

# 插入1310次，每秒0.5次

INSERT 1.31k 0.5/s 15.37 16.19

# 删除100次

DELETE 100 0.0/s 1.17 1.23

REPLACE 0 0/s 0.00 0.00

# 数据库其它操作，不宜占比太高

Com_ 10.60k 4.4/s 124.20

stmt_execut 8.11k 3.4/s 94.93

stmt_close 1.05k 0.4/s 12.30

stmt_prepar 1.05k 0.4/s 12.30

__ SELECT and Sort _____________________________________________________

# 全表扫描，数值越低越好

Scan 9 0.0/s %SELECT: 0.18

# 范围查询

Range 10 0.0/s 0.20

# 联合查询全表扫描

Full join 0 0/s 0.00

Range check 0 0/s 0.00

Full rng join 0 0/s 0.00

Sort scan 0 0/s

Sort range 71 0.0/s

Sort mrg pass 0 0/s

# 查询缓存

__ Query Cache _________________________________________________________

# 缺省为32M

# 如果内存使用接近最大值，则有查询会从缓存中被移走，从而影响下面的Prune值

Memory usage 16.81k of 1.00M %Used: 1.64

# 内存碎片，值越大，碎片越多。一般不超过20%。与query_cache_min_res_unit相关

Block Fragmnt 100.00%

Hits 0 0/s

Inserts 1 0.0/s

# insert/prune是一个波动性的QC指标。一个稳定运行中的QC，insert进QC的查询数量应该大于prune掉

# 的查询数量。如果是1:1，就表示：

# 1. QC大小不够

# 2. mysql试图缓存一切，结果帮了倒忙~

# 但更多的时候是第二种情况。因为QC设置里开启的默认type1就是要求mysql尽可能的缓存一切东西。

# 另一个稍微好一些的方式是type2 demand ，只有在查询使用 `select sql_cache` 时才缓存查询结果

Insrt:Prune 1:1 0/s

# hit/insert用来反映QC的有效性。理想情况是：mysql插入一批稳定的查询到QC里，然后源源不断的命中这批

# 结果。所以，如果QC的有效性足够，这个比值应该是偏向hit的。如果不幸的偏向了insert，那说明QC其实没

# 起到太大的作用。比如说1:1，一次insert用了一次hit，然后就被替换了，这完全违背了使用QC的初衷。不

# 过还有更糟的，比如0.34:1,一次都没用上，就被prune掉了

Hit:Insert 0.00:1

# 表锁报表，MyISAM是表锁

__ Table Locks _________________________________________________________

# 锁等待，总数不要超过10%，否则对性能有很大的影响

Waited 0 0/s %Total: 0.00

# 总数

Immediate 8.28k 3.4/s

# 这里有两个值比较重要。一个是表缓存使用率，哪怕高到100%都行。不过要是真高到100%了，可能你的

# ’table_cache’设置已经不够了，赶紧加大吧。

# 第二个是当前打开表的比率，这个也能协助判断’table_cache’设置是否合理。一般这个值应该小于每秒

# 1次。不过一个负载比较高而又运行的还不错的mysql，可能能达到每秒打开7次表，依然保持100%的表缓存

__ Tables ______________________________________________________________

Open 163 of 2000 %Cache: 8.15

Opened 170 0.1/s

# 如果最大连接数曾经接近过100%，请加大’max_connection’设置。不过事实上，默认的100已经足够绝大多数

# 哪怕相当繁忙的mysql使用了，盲目加大这个设置其实不对。一个mysql链接持续1秒钟，100个就是足足100秒

# 。所以如果连接数太高，或者说一直在慢慢涨，问题很可能在别的地方，比如慢查询、糟糕的索引、甚至DNS

# 解析太慢。在修改这个数的事情，还是先去研究一下为什么100个还不够呢

__ Connections _________________________________________________________

# 最大151，并发最大数是30

Max used 30 of 151 %Max: 19.87

Total 34 0.0/s

__ Created Temp ________________________________________________________

# 在磁盘上创建临时文件

Disk table 0 0/s

# 在内存中创建临时文件，mysql一般也避免在磁盘上创建临时表，除非达到了’tmp_table_size’的阀值。这个

# 阀值会显示在内存(Table)那行的Size列后面，即16M

Table 19 0.0/s Size: 16.0M

File 5 0.0/s

# 这里面有一个需要注意的地方：线程命中率（%Hit）。每个mysql的连接都是一个单独的线程。

# MySQL启动时，只创建不多的几个线程和一个线程缓存，以节省不断创建和销毁线程的开销，哪

# 怕这个开销不怎么明显。当mysql的连接数超过了线程缓存数(由thread_cache_size定义)

# 时，MySQL开始出现线程抖动(‘threadthrash’)。为了接纳新的连接，mysql疯狂的创建新线程，

# 结果自然是线程命中率大幅下滑。

__ Threads _____________________________________________________________

Running 1 of 1

Cached 8 of 9 %Hit: 11.76

Created 30 0.0/s

Slow 0 0/s

__ Aborted _____________________________________________________________

Clients 0 0/s

Connects 0 0/s

__ Bytes _______________________________________________________________

Sent 2.15M 894.0/s

Received 475.84k 198.0/s

# innodb_buffer_pool_size定义了InnoDB存储引擎的表数据和索引数据的最大内存缓冲区大小。

# 和 MyISAM 存储引擎不同， MyISAM 的 key_buffer_size只能缓存索引键，而innodb_buffer_pool_size

# 却可以缓存数据块和索引键。适当的增加这个参数的大小，可以有效的减少InnoDB类型的表的磁盘I/O

# 在一个以 InnoDB 为主的专用数据库服务器上，可以考虑把该参数设置为物理内存大小的 60%-80%

__ InnoDB Buffer Pool __________________________________________________

# 必须避免mysql运行到缓冲池溢出的地步。myisam溢出，只会导致性能下降(索引读写变慢)

# ，而innodb的溢出问题就多了，因为几乎所有东西都依赖缓冲池。所以最好还是配置好自增长缓冲池

# (‘auto-extending buffer pool’)

Usage 70.55M of 127.98M %Used: 55.12

# 读命中率

Read hit 97.08%

Pages

# 空闲页，是使用率（%Used）的对立方

Free 3.68k %Total: 44.88

# 数据页，列%Dirty，展示已经被修改过，但还没有被刷新到磁盘存储的数据页的比率

Data 4.48k 54.68 %Drty: 0.00

# 用于管理分配行锁和自适应哈希索引导致的开销使用的页

Misc 36 0.44

# 目前正在读写、或者因为其他原因无法被刷新的页

Latched 0.00

# 从内存读取的数量, 这个数值可以用来衡量innodb缓冲池的吞吐量,

# 因为几乎所有inondb需要的东西都是在缓冲池里，所以缓冲池的读性能是越快越好。

# 哪怕超过每秒200000次也不是不可能的

Reads 118.58k 49.3/s

# 从磁盘读的数量, 越小越好

From file 3.47k 1.4/s 2.92

# 随机读，innodb启动的随机读取数。只有对表的大部分内容进行随机扫描的时候才会出现

Ahead Rnd 0 0/s

# 顺序读，只有全表扫描才会出现

Ahead Sql 0/s

# 本行显示写的数量以及读写的比率。如果服务器主要操作是update和insert的话，这个值也会比较高。

Writes 11.59k 4.8/s

# 缓冲池的页刷新请求数

Flushes 1.48k 0.6/s

# 一般情况下，innodb缓冲池的写操作是后台运行的。不过，如果出现必须要读写一个页可偏偏没有可用的新

# 页时，（innodb）就只能先等待页的刷新了。这个变量就是这些等待的总数。只要缓冲池的大小设置得当，

# 等待数应该会很小

Wait Free 0 0/s

# innodb锁报表，MyISAM引擎是表锁，而innoDB是行锁。所以当你使用innodb时这几个变量的值非常重要。

__ InnoDB Lock _________________________________________________________

# 等待某行解锁的累积次数，最好为0

Waits 136 0.1/s

# 当前正在等待解锁的行个数，最好为0

Current 0

# 显示了毫秒(ms)级行锁等待数据。分别是总值、平均值和最大值。同样最好是0次。

Time acquiring

Total 266046 ms

Average 1956 ms

Max 6798 ms

# 这部分报告，一般广泛的用于衡量innodb引擎的吞吐量指标。

__ InnoDB Data, Pages, Rows ____________________________________________

Data

# 指的是整个innodb引擎完成所有的数据读取次数。注意：不是整个数据读取字节数或者类型，

# 而是innodb完成的数据读取次数

Reads 3.54k 1.5/s

# 写，和读一样也是次数的统计

Writes 977 0.4/s

# 刷新，同样的，innodb从内存写入磁盘的次数。这个值应该会比前两个小

fsync 170 0.1/s

# 等待，又被分成了三行(108-110)，分别是读、写、刷新的等待次数

Pending

Reads 0

Writes 0

fsync 0

# 这部分包括三种自描述类型：创建、读取、写入，分别用来表示缓冲池中页的创建、读取

# 和写入的数量和速率(即每秒操作数)。

Pages

Created 27 0.0/s

Read 4.45k 1.9/s

Written 1.48k 0.6/s

Rows

Deleted 98 0.0/s

Inserted 1.31k 0.5/s

Read 475.31k 197.8/s

Updated 2.58k 1.1/s