rrqm/s: 每秒进行 merge 的读操作数目.即 delta(rmerge)/s
wrqm/s: 每秒进行 merge 的写操作数目.即 delta(wmerge)/s
r/s: 每秒完成的读 I/O 设备次数.即 delta(rio)/s
w/s: 每秒完成的写 I/O 设备次数.即 delta(wio)/s
rsec/s: 每秒读扇区数.即 delta(rsect)/s
wsec/s: 每秒写扇区数.即 delta(wsect)/s
rkB/s: 每秒读K字节数.是 rsect/s 的一半,因为每扇区大小为512字节.(需要计算)
wkB/s: 每秒写K字节数.是 wsect/s 的一半.(需要计算)
avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区).delta(rsect+wsect)/delta(rio+wio)
avgqu-sz: 平均I/O队列长度.即 delta(aveq)/s/1000 (因为aveq的单位为毫秒).
await: 平均每次设备I/O操作的等待时间 (毫秒).即 delta(ruse+wuse)/delta(rio+wio)
svctm: 平均每次设备I/O操作的服务时间 (毫秒).即 delta(use)/delta(rio+wio)
%util: 一秒中有百分之多少的时间用于 I/O 操作,或者说一秒中有多少时间 I/O 队列是非空的.即 delta(use)/s/1000 (因为use的单位为毫秒)

如果 %util 接近 100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘
可能存在瓶颈.
idle小于70% IO压力就较大了,一般读取速度有较多的wait.
同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)
另外 await 的参数也要多和 svctm 来参考.差的过高就一定有 IO 的问题.
avgqu-sz 也是个做 IO 调优时需要注意的地方,这个就是直接每次操作的数据的大小,如果次数多,但数据拿的小的话,其实 IO 也会很小.如果数据拿的大,才IO 的数据会高.也可以通过 avgqu-sz × ( r/s or w/s ) = rsec/s or wsec/s.也就是讲,读定速度是这个来决定的.

另外还可以参考
svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了),svctm 的大小一般和磁盘性能有关,CPU/内存的负荷也会对其有影响,请求过多也会间接导致 svctm 的增加.await 的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式.如果 svctm 比较接近 await,说明 I/O 几乎没有等待时间；如果 await 远大于 svctm,说明 I/O 队列太长,应用得到的响应时间变慢,如果响应时间超过了用户可以容许的范围,这时可以考虑更换更快的磁盘,调整内核 elevator 算法,优化应用,或者升级 CPU.
队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标,但由于 avgqu-sz 是按照单位时间的平均值,所以不能反映瞬间的 I/O 洪水.

别人一个不错的例子.(I/O 系统 vs. 超市排队)

举一个例子,我们在超市排队 checkout 时,怎么决定该去哪个交款台呢? 首当是看排的队人数,5个人总比20人要快吧? 除了数人头,我们也常常看看前面人购买的东西多少,如果前面有个采购了一星期食品的大妈,那么可以考虑换个队排了.还有就是收银员的速度了,如果碰上了连 钱都点不清楚的新手,那就有的等了.另外,时机也很重要,可能 5 分钟前还人满为患的收款台,现在已是人去楼空,这时候交款可是很爽啊,当然,前提是那过去的 5 分钟里所做的事情比排队要有意义 (不过我还没发现什么事情比排队还无聊的).

I/O 系统也和超市排队有很多类似之处:

r/s+w/s 类似于交款人的总数
平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数
平均服务时间(svctm)类似于收银员的收款速度
平均等待时间(await)类似于平均每人的等待时间
平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少
I/O 操作率 (%util)类似于收款台前有人排队的时间比例.

我们可以根据这些数据分析出 I/O 请求的模式,以及 I/O 的速度和响应时间.

下面是别人写的这个参数输出的分析

上面的 iostat 输出表明秒有 28.57 次设备 I/O 操作: 总IO(io)/s = r/s(读) +w/s(写) = 1.02+27.55 = 28.57 (次/秒) 其中写操作占了主体 (w:r = 27:1).

平均每次设备 I/O 操作只需要 5ms 就可以完成,但每个 I/O 请求却需要等上 78ms,为什么? 因为发出的 I/O 请求太多 (每秒钟约 29 个),假设这些请求是同时发出的,那么平均等待时间可以这样计算:

平均等待时间 = 单个 I/O 服务时间 * ( 1 + 2 + … + 请求总数-1) / 请求总数

应用到上面的例子: 平均等待时间 = 5ms * (1+2+…+28)/29 = 70ms,和 iostat 给出的78ms 的平均等待时间很接近.这反过来表明 I/O 是同时发起的.

每秒发出的 I/O 请求很多 (约 29 个),平均队列却不长 (只有 2 个 左右),这表明这 29 个请求的到来并不均匀,大部分时间 I/O 是空闲的.

一秒中有 14.29% 的时间 I/O 队列中是有请求的,也就是说,85.71% 的时间里 I/O 系统无事可做,所有 29 个 I/O 请求都在142毫秒之内处理掉了.

delta(ruse+wuse)/delta(io) = await = 78.21 => delta(ruse+wuse)/s =78.21 * delta(io)/s = 78.21*28.57 = 2232.8,表明每秒内的I/O请求总共需要等待2232.8ms.所以平均队列长度应为 2232.8ms/1000ms = 2.23,而 iostat 给出的平均队列长度 (avgqu-sz) 却为 22.35,为什么?! 因为 iostat 中有 bug,avgqu-sz 值应为 2.23,而不是 22.35.

$ mysql -u root -ppassword:mysql> create database test; # 创建数据库Query OK, 1 row affected (0.00 sec)mysql> show databases; # 查看数据库是否创建成功+--------------------+| Database           |+--------------------+| information_schema || mysql              || test               |+--------------------+3 rows in set (0.00 sec)mysql> grant all on test.* to user1@'%' identified by '123456' with grant option; # 创建特权管理用户Query OK, 0 rows affected (0.00 sec)mysql> select user,host from mysql.user; # 查看用户创建是否成功+------------------+-----------+| user             | host      |+------------------+-----------+| user1            | %         || root             | 127.0.0.1 || debian-sys-maint | localhost || root             | localhost || root             | server    |+------------------+-----------+5 rows in set (0.00 sec)mysql> show grants for user1; # 查看用户权限+--------------------------------------------------------------------------------------------------+| Grants for user1@%                                                                               |+--------------------------------------------------------------------------------------------------+| GRANT USAGE ON *.* TO 'user1'@'%' IDENTIFIED BY PASSWORD '*6BB...2CA2AD9'                        || GRANT ALL PRIVILEGES ON `test`.* TO 'user1'@'%' WITH GRANT OPTION                                |+--------------------------------------------------------------------------------------------------+2 rows in set (0.00 sec)

GRANT 语法:
 

GRANT privileges (columns)    ON what    TO user IDENTIFIED BY "password"    WITH GRANT OPTION

权限列表:

    
• ALTER: 修改表和索引。
    
• CREATE: 创建数据库和表。
    
• DELETE: 删除表中已有的记录。
    
• DROP: 抛弃(删除)数据库和表。
    
• INDEX: 创建或抛弃索引。
    
• INSERT: 向表中插入新行。
    
• REFERENCE: 未用。
    
• SELECT: 检索表中的记录。
    
• UPDATE: 修改现存表记录。
    
• FILE: 读或写服务器上的文件。
    
• PROCESS: 查看服务器中执行的线程信息或杀死线程。
    
• RELOAD: 重载授权表或清空日志、主机缓存或表缓存。
    
• SHUTDOWN: 关闭服务器。
    
• ALL: 所有权限，ALL PRIVILEGES同义词。
    
• USAGE: 特殊的 "无权限" 权限。

用户账户包括 "username" 和 "host" 两部分，后者表示该用户被允许从何地接入。user1@'%' 表示任何地址，默认可以省略。还可以是 "user1@192.168.1.%"、"user1@%.abc.com" 等。数据库格式为 db@table，可以是 "test.*" 或 "*.*"，前者表示 test 数据库的所有表，后者表示所有数据库的所有表。

子句 "WITH GRANT OPTION" 表示该用户可以为其他用户分配权限。

我们用 root 再创建几个用户，然后由 test 数据库的管理员 user1 为他们分配权限。
 

mysql> create user user2 identified by '123456', user3 identified by 'abcd';Query OK, 0 rows affected (0.00 sec)mysql> select user, host from mysql.user;+------------------+-----------+| user             | host      |+------------------+-----------+| user1            | %         || user2            | %         || user3            | %         || root             | 127.0.0.1 || debian-sys-maint | localhost || root             | localhost || root             | server    |+------------------+-----------+7 rows in set (0.00 sec)

好了，我们退出改用 user1 登录并针对 test 数据库进行操作。
 

mysql> quit # 退出Bye$ mysql -u user1 -p123456 test # 使用新用户登录mysql> select database(); # 确认当前工作数据库+------------+| database() |+------------+| test       |+------------+1 row in set (0.00 sec)mysql> select current_user(); # 确认当前工作账户+----------------+| current_user() |+----------------+| user1@%        |+----------------+1 row in set (0.00 sec)

继续，创建一个数据表。
 

mysql> create table table1 # 创建表    -> (    ->    name varchar(50),    ->    age integer    -> );Query OK, 0 rows affected (0.02 sec)mysql> show tables; # 查看表是否创建成功+----------------+| Tables_in_test |+----------------+| table1         |+----------------+1 row in set (0.00 sec)mysql> describe table1; # 查看表结构+-------+-------------+------+-----+---------+-------+| Field | Type        | Null | Key | Default | Extra |+-------+-------------+------+-----+---------+-------+| name  | varchar(50) | YES  |     | NULL    |       || age   | int(11)     | YES  |     | NULL    |       |+-------+-------------+------+-----+---------+-------+2 rows in set (0.00 sec)mysql> insert into table1 values('Tom', 20); # 插入记录Query OK, 1 row affected (0.00 sec)mysql> select * from table1; # 查询记录+------+------+| name | age  |+------+------+| Tom  |   20 |+------+------+1 row in set (0.00 sec)

接下来我们为 user2, user3 分配权限。
 

mysql> grant select on test.* to user2; # 为 user2 分配 SELECT 权限。Query OK, 0 rows affected (0.00 sec)mysql> grant select on test.* to user3; # 为 user3 分配 SELECT 权限。Query OK, 0 rows affected (0.00 sec)mysql> grant insert, update on test.* to user2; # 再为 user2 增加 INSERT, UPDATE 权限。Query OK, 0 rows affected (0.00 sec)

好了，我们退出，切换成 user2 操作看看。
 

$ mysql -u user2 -p123456mysql> use test; # 切换工作数据库Reading table information for completion of table and column namesYou can turn off this feature to get a quicker startup with -ADatabase changedmysql> select database(); # 验证当前工作数据库+------------+| database() |+------------+| test       |+------------+1 row in set (0.00 sec)mysql> select user(); # 验证当前账户+-----------------+| user()          |+-----------------+| user2@localhost |+-----------------+1 row in set (0.00 sec)mysql> show grants for user2; # 查看当前用户权限，显然后来添加的 INSERT, UPDATE 被添加了。+--------------------------------------------------------------------------------------------------+| Grants for user2@%                                                                               |+--------------------------------------------------------------------------------------------------+| GRANT USAGE ON *.* TO 'user2'@'%' IDENTIFIED BY PASSWORD '*6BB837....2C9'                        || GRANT SELECT, INSERT, UPDATE ON `test`.* TO 'user2'@'%'                                          |+--------------------------------------------------------------------------------------------------+2 rows in set (0.00 sec)

进行操作测试。
 

mysql> insert into table1 values("Jack", 21); # INSERT 操作成功Query OK, 1 row affected (0.00 sec)mysql> update table1 set age=22 where name='Jack'; # UPDATE 操作成功Query OK, 1 row affected (0.00 sec)Rows matched: 1  Changed: 1  Warnings: 0mysql> select * from table1; # SELECT 操作成功+------+------+| name | age  |+------+------+| Tom  |   20 || Jack |   22 |+------+------+2 rows in set (0.00 sec)mysql> delete from table1 where age=22; # DELETE 操作无权限ERROR 1142 (42000): DELETE command denied to user 'user2'@'localhost' for table 'table1'

我们切换回 user1 管理账户，移除 user2 的 UPDATE 权限看看。
 

$ mysql -u user1 -p123456 testmysql> revoke update on test.* from user2; # 移除 UPDATE 权限Query OK, 0 rows affected (0.00 sec)

再次切换回 user2。
 

$ mysql -u user2 -p123456 testmysql> show grants for user2; # UPDATE 权限被移除+--------------------------------------------------------------------------------------------------+| Grants for user2@%                                                                               |+--------------------------------------------------------------------------------------------------+| GRANT USAGE ON *.* TO 'user2'@'%' IDENTIFIED BY PASSWORD '*6B...2AD9'                            || GRANT SELECT, INSERT ON `test`.* TO 'user2'@'%'                                                  |+--------------------------------------------------------------------------------------------------+2 rows in set (0.00 sec)mysql> update table1 set age=23 where name='Jack'; # 不在拥有 UPDATE 权限ERROR 1142 (42000): UPDATE command denied to user 'user2'@'localhost' for table 'table1'

好了，到此我们基本完成了创建用户和分配权限的操作。接下来，我们回到 root 进行修改用户密码和删除用户操作。
 

$ mysql -u root -p123456mysql> set password for user3=password('abcabc'); # 修改用户 user3 密码Query OK, 0 rows affected (0.00 sec)mysql>flush privileges; # 刷新权限表(通常只在直接修改相关管理数据表后需要该操作)Query OK, 0 rows affected (0.00 sec)mysql> revoke all on *.* from user2; # 移除 user2 在所有数据库上的权限 Query OK, 0 rows affected (0.00 sec)mysql> drop user user2; # 删除 user2 账户Query OK, 0 rows affected (0.00 sec)mysql> select user,host from mysql.user; # 验证删除结果+------------------+-----------+| user             | host      |+------------------+-----------+| user1            | %         || user3            | %         || root             | 127.0.0.1 || debian-sys-maint | localhost || root             | localhost || root             | server    |+------------------+-----------+6 rows in set (0.00 sec)

用户 user2 无法再次使用。
 

$ mysql -u user2 -p123456 testERROR 1045 (28000): Access denied for user 'user2'@'localhost' (using password: YES)

试试 user3。
 

$ mysql -u user3 -pabc test # 连接失败！哦，对了，我们修改了密码。ERROR 1045 (28000): Access denied for user 'user3'@'localhost' (using password: YES)$ mysql -u user3 -pabcabc test # 新密码成功mysql> select * from table1; # SELECT 操作成功+------+------+| name | age  |+------+------+| Tom  |   20 || Jack |   22 |+------+------+2 rows in set (0.00 sec)

要修改自己的密码直接执行 "set password = password('new_password');" 即可。

------- 摘要 --------------------------------------

创建用户:

GRANT insert, update ON testdb.* TO user1@'%' IDENTIFIED BY 'password' WITH GRANT OPTION;CREATE USER user2 IDENTIFIED BY 'password';

分配权限:

GRANT select ON testdb.* TO user2;

查看权限:

SHOW GRANTS FOR user1;

修改密码:

SET PASSWORD FOR user1 = PASSWORD('newpwd');SET PASSWORD = PASSWORD('newpwd');

移除权限:

REVOKE all ON *.* FROM user1; 

删除用户:

DROP USER user1;

数据库列表:

SHOW DATABASES;

数据表列表:

SHOW TABLES;

当前数据库:

SELECT DATABASE();

当前用户:

SELECT USER();

数据表结构:

DESCRIBE table1;

刷新权限:

FLUSH PRIVILEGES;

　　使用以下的方法，使SWF文件强制不从浏览器读本地的缓存。或强制其SWF文件每次都去 读取最新的媒体文件

　　确保每次都读取最新的SWF文件

　　1：使用"Expires"标头 这是在HTML文件中告诉浏览器不读取本地缓存

　　在<head> </head> 中间加以下代码

<!-- BEGIN INSERT -->
<META HTTP-EQUIV="Expires" CONTENT="Mon, 04 Dec 1999 21:29:02 GMT">
<!-- END INSERT -->

　　这样的话，每次访问这个文件都会告诉浏览器其缓存版本过期，将重新从服务器端读取最新的文件

　　2：直接告诉浏览器根本就没有缓存

　　在包含SWF文件的HTML页面里的</body>插入：

<!-- BEGIN INSERT -->
<HEAD>
<META HTTP-EQUIV="PRAGMA" CONTENT="NO-CACHE">
</HEAD>
<!-- END INSERT -->

　　没有Cache标头 不支持IE5版本，所以微软建议使用带Cacahe控制标头

　　3：当在HTML页面间连接跳转时

　　在点击超连接时将强制其从服务器上下载最新文档而不是从本地缓存中浏览

　　例如：

<A HREF="stockPrices.htm?1">Current stock prices</A>

　　以上方法将阻止读取本地缓存

　　如何阻止从缓存中读取加载变量

　　问题：

　　当从外部数据源加载数据时，有时浏览器将数据存贮在本地缓存中，这样就导致在调用loadVariables方法加载数据时会从本地缓存中读取数据而代替从原始数据读取的信息。

　　解决：

　　为确保flash加载的是最新的变量，附加一个随机数变量，这样就可以原始档中加载最新的数据

　　例如：

　　方法一：

loadVariables("mypage.asp?nocache=" + random(65000), 0, "POST");

　　方法二：

loadVariables("mypage.asp?nocache=" + getTimer(), 0, "POST");

　　这样确保每次加载的数据是最新的.

http://www.boredpanda.com/404

http://www.catswhocode.com/blog/404

http://www.limpfish.com/404

http://homestarrunner.com/404

http://www.thetruth.com/404

http://www.heinz.com/404

http://dazeofourlives.com/404

http://www.acorncreative.com/404

http://seecoy.com/hereIsOneYouMissed

http://24-7media.de/saadasd

http://retardzone.com/sdfsdf

http://www.dawdle.com/error_page.php

http://www.centerd.com/error.html

http://www.southparkstudios.com/404

http://www.larknews.com/july_2004/5.html

http://www.ddz.net/404/index.htm

http://www.lightpostcreative.com/404

http://www.lileks.com/404

http://www.nickciske.com/404.htm

http://renkoo.com/404.html

http://abduzeedo.com/4023

http://patterntap.com/404

http://sendables.jibjab.com/rfrreerer

http://www.funned.net/404

http://www.zivity.com/404

进行MySQL的配置优化，首先必须找出MySQL的性能瓶颈所在；而SHOW STATUS输出的报告正是用来计算性能瓶颈的参考数据。mysqlreport不像SHOW STATUS那样简单的罗列数据，而是对这些参考数据加以融合计算，整理成一个个优化参考点，然后DBA就可以根据这个优化参考点的值以及该点的衡量标准，进行对应调整。这篇文章既不分析mysqlreport的报告含义，也不说明优化参考点的计算公式和原理，只简单描述使用方法。后面再逐次深入分析。

mysqlreport主页和下载地址
web site:http://hackmysql.com/mysqlreport
download:http://hackmysql.com/scripts/mysqlreport

yum install perl-DBD-MySQL

mysqlreport命令行选项参数

linux-8tpn:/home/kevin/perl # perl mysqlreport  --help
mysqlreport v3.5 Apr 16 2008
mysqlreport makes an easy-to-read report of important MySQL status values.
Command line options (abbreviations work):
   --user USER       Connect to MySQL as USER
   --password PASS   Use PASS or prompt for MySQL user's password
   --host ADDRESS    Connect to MySQL at ADDRESS
   --port PORT       Connect to MySQL at PORT
   --socket SOCKET   Connect to MySQL at SOCKET
   --no-mycnf        Don't read ~/.my.cnf
   --infile FILE     Read status values from FILE instead of MySQL
   --outfile FILE    Write report to FILE
   --email ADDRESS   Email report to ADDRESS (doesn't work on Windows)
   --flush-status    Issue FLUSH STATUS; after getting current values
   --relative X      Generate relative reports. If X is an integer,
                     reports are live from the MySQL server X seconds apart.
                     If X is a list of infiles (file1 file2 etc.),
                     reports are generated from the infiles in the order
                     that they are given.
   --report-count N  Collect N number of live relative reports (default 1)
   --detach          Fork and detach from terminal (run in background)
   --help            Prints this
   --debug           Print debugging information
Visit http://hackmysql.com/mysqlreport for more information

选项 解释
- -user 连接MySQL的用户名
- -password 连接MySQL的用户密码。命令行上出现该选项但没有给出参数时，mysqlreport将在用户回车后提示输入密码
- -host MySQL服务器地址
- -port MySQL服务器的开发端口
- -socket 本地MySQL UNIX域套接口路径
- -no-mycnf 该选项指引mysqlreport不要读取 ~/.my.cnf，默认情况下会去读取这个文件。- -user 和 - -password 总是覆盖从 ~/.my.cnf 中取得的参数
- -infile 从status文件读取数据，代替从服务器上读取
- -outfile 打印报告后，将报告同时写入该选项指定的文件中。mysqlreport 的内部机制总是先将报告写入临时文件中，然后将该临时文件里的内容打印到屏幕上。如果指定了- -outfile选项，则将临时文件拷贝成 指定的文件。如果指定了选项- -email，则会删除临时文件
- -email 打印报告后，将结果发送到指定的邮箱。该选项需要使用/usr/sbin/目录下的sendmail程序，因此无法在windows 平台下使用。/usr/sbin/sendmail可以符号链接到 qmail，或者任何其他能模拟sendmail -t方式的MTA程序。邮件来源是：mysqlreport，主题是：MySQL status report on HOST，HOST是mysqlreport所在的主机名，可能是读取到的- -host值，默认是localhost
- -flush-status 打印报告后，运行FLUSH STATUS命令
- -relative mysqlreport通常产生从MySQL启动以来的状态报告。指定- -relative选项可产生相对于前次报告以来的相关报告。
如果选项参数是一个整数，程序每隔指定的秒数后再次产生一份状态报告，报告次数由- -report-count选项指定。默认产生1份相关报告。例如，指定- -relative的值为60，则会产生2份报告：第一份基本报告马上生成，第二份相关报告在60秒后生成。第二份报告中的数值和前面的那份相关。例如，前者总共有10.00k次查询，在这60秒的间隔时间里接受了新的1.00k次查询，则后者的总查询次数是1.00k而非11.00k次。

如果选项参数是本地文件列表（就像- -infile选项那样），程序会按照参数中文件的顺序来依次产生状态报告。文件列表中的文件应该以空格分隔。以文件产生时间依次排列文件就显得很重要，较早产生的文件应该放在列表的前面。第一个文件中必须有系统变量，例如：key_buffer_size、table_cache 等。每个文件中可以有多组”SHOW STATUS”的结果。注意：通过 “mysqladmin -r -i N extended” 产生的状态文件无法使用，因为 mysqladmin的-r参数已经令其产生了具有相对性的状态值了。

由于mysqlreport首先会把状态报告写到临时文件中，如果- -relative的参数是整数时，mysqlreport会显示它把文件写到哪了。那么就可以直接通过查看这些文件内容来观察服务器的状况
 
- -report-count 生成N份相关的报告。本选项只有在同时启用- -relative选项后才有效。mysqlreport会自动产生N+1份报告：第一份基本报告，以及后面的N份相关报告
- -detach 本选项使得mysqlreport派生新进程，从终端上脱离转入后台继续运行。派生新进程后，mysqlreport 会报告它把结果写入了哪个临时文件。本选项需要- -outfile或- -email中的一个，如果这两个选项都没有给出，则产生的临时文件就会被删除，因为自派生出新进程后，无法再将结果打印到终端屏幕上了。本选项如果和- -relative选项一起使用的话就更有意义了，这样mysqlreport就能定时报告信息，而无需人工干预获得报告。例如使用如下命令，就能让mysqlrepot隔一个小时再次产生一次报告，并将结果发送到指定的信箱：perl mysqlreport - -relative=3600 - -detach - -email=host@domain.com。一个小时候后，mysqlreport通过email发送报告，删除临时文件，并且干净地终止
- -help 打印帮助信息
- -debug 打印调试信息

使用mysqlreport的简单例子
1.连接远程数据库192.168.12.14
perl mysqlreport - -host=192.168.12.14 - -user=db_user - -password=db_user_password

2.通过本地UNIX域套接口文件/data/mysql_data/mysql.sock连接本地数据库
perl mysqlreport - -user=root - -password=root_password - -socket=/data/mysql_data/mysql.sock

3.将输出报告写入文件/data/mysql_data/report/mysqlreport.txt
perl mysqlreport - -user=root - -password=root_password - -socket=/data/mysql_data/mysql.sock - -outfile=/data/mysql_data/report/mysqlreport.txt

报告说明：
# /usr/local/mysql/bin/mysqlreport --user root -password password

Use of uninitialized value in multiplication (*) at /usr/local/mysql/bin/mysqlreport line 829.  
Use of uninitialized value in formline at /usr/local/mysql/bin/mysqlreport line 1227.  
MySQL 5.1.34-log         uptime 0 1:31:10       Fri Jan 15 12:39:12 2010  
 
__ Key _________________________________________________________________  
Buffer used    12.33M of 256.00M  %Used:   4.81  
  Current      41.80M            %Usage:  16.33  
Write hit      52.74%  
Read hit       99.74%  
 
__ Questions ___________________________________________________________  
Total         434.70k    79.5/s  
  DMS         265.94k    48.6/s  %Total:  61.18  
  QC Hits     166.09k    30.4/s           38.21  
  +Unknown      1.09k     0.2/s            0.25  
  Com_          1.08k     0.2/s            0.25  
  COM_QUIT        495     0.1/s            0.11  
Slow 1 s           89     0.0/s            0.02  %DMS:   0.03  Log:  ON  
DMS           265.94k    48.6/s           61.18  
  SELECT      149.52k    27.3/s           34.40         56.22  
  UPDATE      115.33k    21.1/s           26.53         43.37  
  INSERT          899     0.2/s            0.21          0.34  
  DELETE          193     0.0/s            0.04          0.07  
  REPLACE           0       0/s            0.00          0.00  
Com_            1.08k     0.2/s            0.25  
  change_db       446     0.1/s            0.10  
  set_option      396     0.1/s            0.09  
  show_status     115     0.0/s            0.03  
 
__ SELECT and Sort _____________________________________________________  
Scan              190     0.0/s %SELECT:   0.13  
Range          45.43k     8.3/s           30.38  
Full join           0       0/s            0.00  
Range check         0       0/s            0.00  
Full rng join       0       0/s            0.00  
Sort scan          11     0.0/s  
Sort range      8.39k     1.5/s  
Sort mrg pass       0       0/s  
 
__ Query Cache _________________________________________________________  
Memory usage   63.62M of 256.00M  %Used:  24.85  
Block Fragmnt   6.68%  
Hits          166.09k    30.4/s  
Inserts       149.29k    27.3/s  
Insrt:Prune 149.29k:1    27.3/s  
Hit:Insert     1.11:1  
 
__ Table Locks _________________________________________________________  
Waited          3.76k     0.7/s  %Total:   1.41  
Immediate     262.48k    48.0/s  
 
__ Tables ______________________________________________________________  
Open               40 of  512    %Cache:   7.81  
Opened             58     0.0/s  
 
__ Connections _________________________________________________________  
Max used            8 of  500      %Max:   1.60  
Total             497     0.1/s  
 
__ Created Temp ________________________________________________________  
Disk table          1     0.0/s  
Table             144     0.0/s    Size: 256.0M  
File                6     0.0/s  
 
__ Threads _____________________________________________________________  
Running             1 of    5  
Cached              3 of   32      %Hit:  98.39  
Created             8     0.0/s  
Slow                0       0/s  
 
__ Aborted _____________________________________________________________  
Clients             0       0/s  
Connects            6     0.0/s  
 
__ Bytes _______________________________________________________________  
Sent          173.88M   31.8k/s  
Received       49.21M    9.0k/s  
 
__ InnoDB Buffer Pool __________________________________________________  
Usage         304.00k of   8.00M  %Used:   3.71  
Read hit       84.81%  
Pages  
  Free            493            %Total:  96.29  
  Data             19                      3.71 %Drty:   0.00  
  Misc              0                      0.00  
  Latched                                  0.00  
Reads              79     0.0/s  
  From file        12     0.0/s           15.19  
  Ahead Rnd         1     0.0/s  
  Ahead Sql         0       0/s  
Writes              0       0/s  
Flushes             0       0/s  
Wait Free           0       0/s  
 
__ InnoDB Lock _________________________________________________________  
Waits               0       0/s  
Current             0  
Time acquiring  
  Total             0 ms  
  Average           0 ms  
  Max               0 ms  
 
__ InnoDB Data, Pages, Rows ____________________________________________  
Data  
  Reads            25     0.0/s  
  Writes            3     0.0/s  
  fsync             3     0.0/s  
  Pending  
    Reads           0  
    Writes          0  
    fsync           0  
 
Pages  
  Created           0       0/s  
  Read             19     0.0/s  
  Written           0       0/s  
 
Rows  
  Deleted           0       0/s  
  Inserted          0       0/s  
  Read              0       0/s  
  Updated           0       0/s 

Report Header: Line 1

报表的第一行包含了三样不同的资讯：MySQL Server 的版本、自上次啟动后已经过多少时间、目前 Server 的日期与时间。有些人会定时让系统自动产生报表(eg. cron)然后用程序去分析进行分析，此时表头将可用来协助您辨识出不同时间点的报表。对於那些租用或使用虚拟主机的管理者，表头可以协助您了解自己所需面对的是什么样的 Server。MySQL Server 版本可以指出该 Server 有提供或没有提供那些功能，而它的 Uptime 则表示该报表具有多大的代表性。Uptime 是重要的指标，可让您了解此份报表所包含的资讯是否可能有偏误，一般来说 Uptime 最少要有一小时会比较适当，甚至光是一小时其实也还不够。例如您的 Server 可能已执行了六个小时，但此六小时皆是在使用率最低的午夜，此时产生出的报表就很不具有代表性。最理想的情况下，你会希望 MySQL Server 至少已经执行了一整天，这样子一来你就可以确定报表中的资讯已包含了 Server 负载的高峰与低峰期，而不是只包含其中之一。在范例报表中 Server 只执行了 34 分鐘，因此该报表的代表性是不足的，但因为这只是用来做范例，也就没什么关係。

Key Report: Lines 3 - 7

第一个主要报告区块就是 Key Report，因为 Key(Indexes, 索引)是所有资讯中最重要的一项。虽然此报表无法告知您 Server 是否有善用 Index，但它可以告诉您 Server 对於 Shared Key Buffer 的使用状态。请注意，这里所指的 Key Buffer 是指 MyISAM Storage Engine 所使用的 Shared Key Buffer，InnoDB 所使用的 Key Buffer 并不包含在内。

MySQL Server 支援许多种不同类型的资料表(比较正式的说法是 Storage Engine)，你可以将它们想像为各种不同的资料结构，而不同的 Storage Engine 各有其优缺点。其中 MySQL Server 预设是使用 MyISAM Storage Engine。

MySQL Server 的 Buffer 大略可分为二种：
1. Global Buffer：由所有 Client 所共用的 Buffer

key_buffer
innodb_buffer_pool
innodb_log_buffer
innodb_additional_mem_pool
net_buffer ...等等

2. Thread Buffer：个别的 Connection 所需佔用的 Buffer

例如：
sort_buffer
myisam_sort_buffer
read_buffer
join_buffer
read_rnd_buffer ...等等

计算 Server 至少需使用的总记忆体数量的方式为：
min_memory_needed = global_buffer + (thread_buffers * 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 哪些资料？

答案是：
MySQL 只会 Cache 索引，也就是 *.MYI 档案，而 Row Data(*.MYD) 则是交由作业系统来负责 Cache。

接下来我们再回到 Key Buffer，有个很重要的问题我们一直没有回答，就是『到底 Key Buffer 要设定多少才够呢？』。如前所述，MySQL 只会 Cache 索引(*.MYI)，因此您只要将资料库中所有的 MYI 档案加总起来，你就会知道大概要设为多少。

Buffer used: Line 4

身为 MySQL 的管理者您通常会问的第一个问题是：『Server 到底用掉了多少 key buffer？』。如果您发现 MySQL 只使用了一小部份的 Key Buffer，这并不是什么需要注意的问题，因为 MySQL 只会在需要的时候才实际分配与使用 System RAM。也就是说，当你设定 MySQL 可使用 512MB 的 RAM 时，并不代表 MySQL 啟动的时候将佔用 512MB 的 RAM(只有在 MySQL 认为需要这么做的时候才会)。报表中的第四行(Buffer used)指出 MySQL "曾经" 耗用过的最大记忆体数量，因此目前 "正在使用" 的记忆体数量有可能少於（甚至大於）这个数字。MySQL 称此数值为 "High Water Mark"，但在报表的下一行我们将会看到它并不总是如此。无论如何，从　Buffer used 我们通常可以看出 key_buffer_size 这个系统变数值是否设定的够大，如果你的 MySQL 已经使用了 80~90% 以上的 Key Buffer，你就应该要调高 key_buffer_size。注意，Buffer used 永远不会有使用率超过 95% 的情况，因为 MySQL 的官方文件中指出 Share Key Buffer 中有部份将会挪用给内部资料结构使用，因此当 Buffer used 指出 Share Key Buffer 的使用率高达 95% 时，其实在实务上等於是已使用了 100% 的 Share Key Buffer。在这个例子中 Server 只使用了 380KB(0.07%) 的 Share Key Buffer，看到这里也许您会判断 Server 的 Share Key Buffer 是十分充足的，但请勿太早下定论，我们必须要接著考量报表中的下一行才能做出客观的判断......。

Current: Line 5

mysqlreport 使用 Key_blocks_unused 这个系统变数来决定目前 MySQL "正在使用" 的 Share Key Buffer 大小，只有在 MySQL Server 4.1.2 以上的版本才会有这个功能。如果报表中的上一行(Buffer used)真的有如 MySQL 官方文件中所说的是 "High Water Mark"，那么 Current 所载明的数值应该永远会小於或等於它。但在接下来的例子中我们将会看到，事情并不总是如此。目前这台 Server 已经使用了大约 60MB(12%) 的 Share Key Buffer，这是一个好现象因为它代表了你的 Share Key Buffer 仍然十分充足。Current 与 Buffer used 合在一起看即可提供一个很有用的指标，告诉您目前的 key_buffer_size 是否充足。

设定 key_buffer_size 的方式也很简单，只要直接修改 MySQL 的设定档然后重新啟动 Server 即可。例如若要将 Key Buffer 设定为 2000MB，则只要在 /etc/my.cnf 中加上：
[mysqld]
key_buffer_size=2000M

Write ratio: Line 6

索引(Indexes, Keys)主要是在记忆体内(RAM-Based)进行操作的，索引之所以如此有用有部份原因就归功於它们主要是在 RAM 里面运作，因此拥有极高的存取性能，不像储存在硬盘中的资料存取速度非常慢。然而，不可否认的是 MySQL 终究还是必须从硬盘中将索引读入 RAM 或是将储存在 RAM 中的索引写回硬盘之中。Write ratio 标示著 MySQL 将索引写入硬盘与 MySQL 将索引写入 RAM 的比值(Write Ratio = MySQL 将索引写入硬盘的次数 / MySQL 将索引写入 RAM 的次数)。具有接近於 1 的 Write Ratio 并不是一件很罕见的事，就像 MySQL 官方手册中所说的，如果你的 MySQL 最主要的活动是 Update、Insert 等等，那么 Write Ratio 将会很接近於 1。Write Ratio 若大於 1 表示 MySQL 将索引写入硬盘的次数大於将索引写入 RAM 的次数，很少有 MySQL Server 的 Write Ratio 会大於 1，绝大部份都应该会小於 1，即便是负载非常重的 Server。

Read ratio: Line 7

Read Ratio 比 Write Ratio 来得重要一些，它标示了 MySQL 从硬盘读取索引与从 RAM 读取索引的比值(Read Ratio = MySQL 从硬盘读取索引的次数 / MySQL 从 RAM 读取索引的次数)。Read Ratio 的值应该要是 0.00 或 0.01，若大於这个值则表示 Server 有问题需要进一步的调查，通常此问题的成因是 Share Key Buffer 设得太小造成 MySQL 需要不断地从硬盘中读取所需要的索引资讯，而这个动作是十分没有效率的并且完全抵消了使用索引可以带来的好处。在 Server 刚啟动的头一个小时 Read Ratio 很常会出现大於 0.01 的数值，但 Server 执行过一阵子后它应该(也必须)降低至 0.01 或是 0.00。

Questions Report: Lines 9 - 26

第二个主要的报表区块，Questions，是第二重要的资讯，因为它可以告诉你 MySQL 到底都在忙些什么事情。Questions 包含了 SQL queries 以及 MySQL protocol communications。大部份的人都只在意 Server 每秒可以处理多少查询(Queries Per Second, QPS)，但若以整个 Server 的观点来考量，QPS 其实是非常不精确的数值，它无法有效的告诉您 Server 的整体运作状况。而 Questions 则提供了较完整的资讯，让您一窥 Server 的全貌。

Total: Line 10

第一个栏位单纯的记载 MySQL 总共回应过多少查询，第二个栏位则记录回应的频率(QPS)，当大部份的人说『我的 Server 平均每秒处理 XXX 个查询』时，他们指的其实就是第二个栏位所记录的回应频率。此时你应该要反问他们『在那 XXX 个查询之中，MySQL 到底做了哪些事情？』，接下来 mysqlreport 将可以协助您回答此问题......。

Distribution of Total Queries (DTQ): Lines 11 - 15

所有的 Questions 可以大致区分为五个不同的类别：
1.Data Manipulation Statements (DMS)
2.query cache hits (QC Hits)
3.COM_QUIT
4.all other Com_ commands
5.Unknown

这五个类别将会展示在 Lines 11 至 15，但它们的顺序是会改变的。mysqlreport 预设是以查询的总数(第一个栏位)来排序，次数越多排得越上面，让您可以快速的分辨出 MySQL 大部份时间都在忙些什么东西。理想的情况下，你会希望 MySQL 把大部份的时间都花在 DMS 与 QC Hits 这两个类别，因为这两个类别才是真正在 "完成正事" 的类别。COM_QUIT、Com_、与 Unknown 也有其存在的必要，但它们应该只佔了其中的一小部份。在继续深入介绍之前，也许你会好奇第三个栏位是做什么用的，它代表了该分类(例如 DMS)佔全部 Queries 的百分比；若是在子分类(例如 Select)中，则表示该子分类佔所属分类(例如 DMS)的百分比。在此范例中 DMS 佔了所有 Queries 的 82.84%，这是一个很好的现象。

Data manipulation statements(DMS) 包含了：ELECT, INSERT, REPLACE, UPDATE, 与 DELETE(技术上来说，其实不只这几个类别但 mysqlreport 只会用到这几类)。基本上，你可以将 DMS 想成是 MySQL 真正有在做些 "有用的事" 的情况，因此你会希望 DMS 是 MySQL 最忙著处理的事情。

QC Hits 是 MySQL 不需要实际执行 Query 而只要直接从 Query Cache 中即可找到所需资料的次数。拥有高比例的 QC Hits 是让人梦寐以求的事，因为从 Query Cache 直接存取所需要的资料是十分快速且有效率的。然而大部份的 MySQL Server 因为各种原因，而无法具有非常有效率的 Query Cache。在本范例中 QC Hits 佔了所有 Questions 的 16.91%，这是非常好的情况。然而，千万不要被这个数值给误导了，在报表中的 38 至 45 行(Query Cache Report)将会告诉您完全不同的状况。这是一个很好的范例，展示了 mysqlreport 可以做为深入、相互参照与比对的分析工具。当 QC Hits 看来似乎十分完美时，这个 Server 的 Qeury Cache Report 却可以明确的告诉您其实事情没有表面上看起来的那样完美，我们在稍后会在回到这个问题。

COM_QUIT 算是比较不重要的类别，若您不是真的很有兴趣其实您大可忽略这个类别的内容。

COM_ 这个类别代表著所有 MySQL 所执行过的指令，通常与 MySQL protocol 相关。在正常的情况下，你会希望这个类别所佔的比例越低越好，因为当这个数值很高的时候就表示 MySQL 正忙碌於无关紧要的事情上。若这个数值很高通常代表 MySQL 正遭遇到某些很奇怪的问题，当我们深入讨论 COM_ 的子类别的时候，我们会在回来探讨这个问题。

Unknown 是推论出来的类别，在理想的状况下，之前所述的四个分类加总起来应该要等於 Questions 总数，但它们通常不会刚好等於。这是因为有些 Questions MySQL 在处理时会增加 Total Questions 的计数器，但却没有相对应的系统变数用来记录所执行过的 Questions。在不同的 Server 上这个数值的变异很大，在有些 Server 上这个数值非常的高，在有些 Server 上则非常的低，但在大部份的情况下它应该要维持在很低的水準才是。如果这个数值非常的高，可能代表 MySQL Server 有什么地方出了问题。

Slow: Line 16

第 16 行非常的重要：它记录了 MySQL 总共执行了多少次 Slow Query。Slow Query 就是指执行所需时间超过某个时间区间的 Query，例如执行超过 10 秒的 Query。用来判定是否为 Slow Query 的时间区间是可以透过 long_query_time 这个系统变数来设定的，MySQL 预设 long_query_time 为 10 秒，但通常我们会将它设定为 5 秒。在最理想的情况下，我们会希望看到这个数值等於零，但通常这数值不会是零。一般来说 Slow Query 佔 Total Questions 的比例应该要低於 0.05，Slow Query 的次数(第一个栏位)本身不是很重要，真正需要注意的是 Slow Query 佔 Total Questions 的比例，若这比例偏高就代表 Server 有些问题需要解决。第四个栏位中的『%DMS: 』表示 Slow Query 在所有 DMS 中所佔的比例。

DMS: Lines 17 - 22

DMS 的子分类项目可以告诉我们，这台 MySQL Server 是属於哪一个类型的 MySQL Server，例如它是著重在 SELECT 操作或是 INSERT 操作，大部份的 MySQL Server 都是著重在 SELECT 操作。知道某台 Server 是属於哪一个类型的 MySQL Server 有助於我们思考报表中的其他资讯，例如一台著重在 SELECT 操作的 MySQL Server 的 Write Ratio 应该会非常的接近 1，并有著较高的 Lock 时间。同时它也隐含了一个意义，就是也许你可以考虑使用 InnoDB Storage Engine，因为 MySQL 预设採用的 MyISAM Storage Engine 所提供的 Lock 层级只有 Table Lock(只能针对整个资料表锁定)，而 InnoDB 则提供 Row Lock 层级的锁定机制(可只针对特定的 ROW 进行锁定，减少等待时间)。若是著重在 SELECT 操作的 Server，它的 Read Ratio 应该会接近於零，并有著非常低的 Table Lock 时间。

在范例中的 Server 是属於著重在 SELECT 操作的 Server：65.72% 的 Questions 是 SELECT(第三个栏位)、79.33% 的 DMS Questions 是 SELECT(第四个栏位)。很明显的，这是台著重在 SELECT 操作的 Server，知道了此项事实之后，我们才有办法对其进行最佳化。

Com_: Lines 23 - 26

这个子分类只有在它的值偏高的时候才需要注意，因为过高的值表示 MySQL 正在忙著处理 "程序方面的东西"，而不是回应使用者的查询。对大部份的 Server 来说这里应该都不会出现偏高的数值，但您最好还是定期的检查一下。

SELECT and Sort Report: Lines 28 - 36

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

Query Cache Report: Lines 38 - 45

Query Cache Report 只有在 MySQL 有支援 Query Cache，以及 Query Cache 功能有开啟的情况下才会有这段资讯出现。

Memory usage: Line 39

此项目指出 Query Cache 的使用状况，若系统已达到 Query Cache 的上限则会连带影响到 Prunes Value，因为当配给的 Memory 不足时，MySQL 必须不断地消除 RAM 中较不常使用的资料以挪出空间摆放新的资料。

Block Fragmnt: Line 40

这个数值越高表示 Query Cache 的 Fragment 状况越严重，通常它会界於 10%~20% 之间。在此范例中 Block Fragmnt 为 13.05%，这是可接受的情况，当然你也可以调整 query_cache_min_res_unit 的值来降低 Block Fragmnt。

Hits, Inserts, Prunes: Lines 41 - 43

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

Insrtrune and Hit:Insert Ratios: Lines 44 - 45

第 44 行中的 Insert 与 Prune 的比值可显示 Query Cache 的挥发性。在一个高度稳定的 Query Cache 中，Insrt 的值应该要高於 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 的资料，你可以使用 SQL_NO_CACHE 来明确的告诉 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 或许可以解决此问题。

Table Locks Report: Lines 47 - 49

这个部份包含了两项资讯：第一项是 Waited，代表 MySQL 需要等待以取得 table lock 的次数。第二项是 Immediate，表示 MySQL 不需要等待即可立刻取得 table lock 的次数。对资料库来说『等待』几乎可以肯定是一件很不好的事情，因此 Waited 的值应该要越小越好。最具有代表性的是第三个栏位(Waited 佔所有 table lock 的百分比)，这个数值应该要小於 10%，大於这个值就表示 table/query 的索引设计不良或是有过多的 Slow Query。

Tables Report: Lines 51 - 53

Tables Report 同样包含了二项资讯：第一是 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 Report: Lines 55 - 57

Connections Report 所代表的意义与 Tables Report 相似，请各位以此类推。比较需要注意的是：若你发现 Connections 的使用率接近 100%，也许你会想调大 max_connections 的值以允许 MySQL 的 Client 建立更多连线。然而，这通常是一种错误。我们常常可以发现很多网路上的资料会教我们要调大 max_connections，但却从来没有给一个明确的理由。事实上，max_connections 的预设值(100)，就算是对於负载十分沉重但有良好调校过的 Server 都已十分足够。MySQL 对於单一连线的资料处理通常只需要零点几秒的时间即可完成，就算是最大只能使用 100 个连线也够让你用上很长一段时间。若是您的 Server 有著非常高的最大连线数(max connections)或是单一连线需要很长时间才可完成，那么问题八成不是 max_connections 的值不够大而是在别的地方，例如 slow queries、索引设计不良、甚至是过於缓慢的 DNS 解析。在您将 max_connections 的值调到 100 以上之前，您应该要先确定真的是因为 Server 过於忙碌而需要调高此数值，而不是其他地方出了问题。每秒平均连线数有可能会很高，事实上，若这个值很高而且 Server 的运作十分顺畅，那么这通常会是一个好现象，无需担心。大部份 Server 的每秒平均连线数应该都会低於 5/s。

Created Temp Report: Lines 59 - 62

MySQL 可以建立暂时性的资料表，它可建立在硬盘中、档案里、或是 RAM 之中，而 Created Temp Report 则提供了相关的数据供您参考。这些数据大多是相对而言，没有一定的标準，但将暂时性的资料表建立在硬盘中是十分没有效率的，因此 Disk table 的值最好是三者中最小的一个。当暂时性的资料表被建立在硬盘中，表示此资料表没有办法被放进 RAM 里面（因为 tmp_table_size 的值设得不够大）。

Threads, Aborted, Bytes Reports: Lines 64 - 76

这几个部份大多没什么好解释的，只有一个项目值得特别说明：第 66 行的最后一个栏位(%Hit)。每一个连接到 MySQL 的连线都是由不同的 Thread 来处理，当 MySQL 啟动时会预先建立一些 Threads 并保留在 Thread Cache 中，如此一来 MySQL 就不用一直忙著建立与删除 Threads。但当每秒最大连线数大於 MySQL 的 Thread Cache 时，MySQL 就会进入 Thread Thrash 的状态：它不断地建立新的 Threads 以满足不断增加的连线的需求。当 Thread Thrash 发生时，%Hit 的数值就会降低。在本范例中 %Hit 的值为 0.05%，这是非常不好的，因为它表示几乎每一个新进来的连线都会造成 MySQL 建立新的 Thread。我们可以看到在此范例中造成此现象的原凶就在第 66 行的第一个栏位，我们可以发现 Thread Cache 的值为 0，因此 thread_cache_size 的值需要调大。

话说回来，究竟 %Hit 接近於零真的有什么关係吗？Jeremy Zawondy 曾在部落格上说到：Thread caching 并不是我们最需要关心的问题，但当你解决了所有其他更严重的问题之后，它就会是最严重的问题。(hread caching really wasn't the worst of our problems. But it became the worst after we had fixed all the bigger ones.)

split 命令允许你 你用下面的方法把输出分解成操作系统可以接受的大小。 比如，让每个块大小为 1 兆字节：

pg_dump dbname | split -b 1m - filename
用下面命令恢复：

createdb dbname
cat filename* | psql dbname

    使 用客户化转储格式. 如果PostgreSQL是在一个安装了zlib 压缩库的系统上制作的，那么客户化转储格式将在写入输出文件的时候压缩数据。 它会生成和使用 gzip 类似大小的转储文件，但是还附加了一个优点：你可以有选择地恢复库中的表。 下面的命令用客户化转储格式转储一个数据库：

pg_dump -Fc dbname > filename
客户化格式的转储不是脚本，不能用于 psql， 而是需要使用 pg_restore 转储。 请参考 pg_dump 和 pg_restore 的手册获取细节。

备份：pg_dump -h localhost -p 5432 -U tradesns -W -F c -b -v -f "/home/tradeworkwangbin/us2010.backup" us2010
恢复：pg_restore -h 192.168.0.100 -p 5432 -U postgres -W -d us2011 -v "/root/us2010.backup"

注意
处于向下兼容的考虑，缺省的时候 pg_dump 并不转储大对象。 要转储大对象，你必须使用客户化或者 tar输出格式， 并且在 pg_dump 中使用-b选项。