mysqlreport是mysql性能监测时最常用的工具，对了解mysql运行状态和配置调整都有很大的帮助。找了一些mysql的资料，发现 大多数是关于php+mysql开发的，服务配置基本就是固定的几条。干脆找上mysqlreport的官网，啃下来这篇指南。翻译都是随着我个人的语言 习惯，对直接能用mysql命令上看到结果的英文则保留下来。方便以后查找：

原文地址：http://hackmysql.com/mysqlreportguide

《mysqlreport指南》

本指南的写作目的是解释mysqlreport上出具的各种数据。通过指南，你可以在阅读完mysqlreport的报告后，完整的解释并且理解一个最根本的问题——而这也正是你使用mysqlreport的目的所在——（我的）MySQL服务器到底运行的怎么样？

当前的mysqlreport版本会自动生成一份尽可能完整的数据报表，最多可达14节121行。您不必再像以前那样输入各种各样的参数定义了。不过如果您的mysql服务配置上关闭了某些部分的话，报表的相关部分也会随之关闭。比如，你关闭了query cache，那么mysqlreport的第4节’Query Cache’也就不存在了。所以报表长度是浮动的。

为了便于理解和观察，本指南采用了对一份完整报表做出逐行解释的方法。下面就是将要被详细解析的那份报表，为了方便，在最前端加上了行号。

1 MySQL 5.0.3              uptime 0 0:34:26       Fri Sep  1 19:46:02 2006
2
3 __ Key _________________________________________________________________
4 Buffer used   380.00k of 512.00M  %Used:   0.07
5   Current      59.32M            %Usage:  11.59
6 Write hit      97.04%
7 Read hit       99.58%
8
9 __ Questions ___________________________________________________________
10 Total          98.06k   47.46/s
11   DMS          81.23k   39.32/s  %Total:  82.84
12   QC Hits      16.58k    8.02/s           16.91
13   COM_QUIT        200    0.10/s            0.20
14   Com_            131    0.06/s            0.13
15   -Unknown         82    0.04/s            0.08
16 Slow 5 s            0    0.00/s            0.00  %DMS:   0.00  Log:  ON
17 DMS            81.23k   39.32/s           82.84
18   SELECT       64.44k   31.19/s           65.72         79.33
19   INSERT       16.75k    8.11/s           17.08         20.61
20   UPDATE           41    0.02/s            0.04          0.05
21   REPLACE           0    0.00/s            0.00          0.00
22   DELETE            0    0.00/s            0.00          0.00
23 Com_              131    0.06/s            0.13
24   change_db       119    0.06/s            0.12
25   show_fields       9    0.00/s            0.01
26   show_status       2    0.00/s            0.00
27
28 __ SELECT and Sort _____________________________________________________
29 Scan               38    0.02/s %SELECT:   0.06
30 Range              14    0.01/s            0.02
31 Full join           3    0.00/s            0.00
32 Range check         0    0.00/s            0.00
33 Full rng join       0    0.00/s            0.00
34 Sort scan          14    0.01/s
35 Sort range         26    0.01/s
36 Sort mrg pass       0    0.00/s
37
38 __ Query Cache _________________________________________________________
39 Memory usage   17.81M of  32.00M  %Used:  55.66
40 Block Fragmnt  13.05%
41 Hits           16.58k    8.02/s
42 Inserts        48.50k   23.48/s
43 Prunes         33.46k   16.20/s
44 Insrt:Prune    1.45:1    7.28/s
45 Hit:Insert     0.34:1
46
47 __ Table Locks _________________________________________________________
48 Waited          1.01k    0.49/s  %Total:   1.24
49 Immediate      80.04k   38.74/s
50
51 __ Tables ______________________________________________________________
52 Open              107 of 1024    %Cache:  10.45
53 Opened            118    0.06/s
54
55 __ Connections _________________________________________________________
56 Max used           77 of  600      %Max:  12.83
57 Total             202    0.10/s
58
59 __ Created Temp ________________________________________________________
60 Disk table         10    0.00/s
61 Table              26    0.01/s    Size:  4.00M
62 File                3    0.00/s
63
64 __ Threads _____________________________________________________________
65 Running            55 of   77
66 Cache               0              %Hit:    0.5
67 Created           201    0.10/s
68 Slow                0    0.00/s
69
70 __ Aborted _____________________________________________________________
71 Clients             0    0.00/s
72 Connects            8    0.00/s
73
74 __ Bytes _______________________________________________________________
75 Sent           38.46M  18.62k/s
76 Received        7.98M   3.86k/s
77
78 __ InnoDB Buffer Pool __________________________________________________
79 Usage           3.95M of   7.00M  %Used:  56.47
80 Read hit       99.99%
81 Pages
82   Free            195            %Total:  43.53
83   Data            249                     55.58 %Drty:   0.00
84   Misc              4                      0.89
85   Latched           0                      0.00
86 Reads         574.56k     0.6/s
87   From file       176     0.0/s            0.03
88   Ahead Rnd         4     0.0/s
89   Ahead Sql         2     0.0/s
90 Writes        160.82k     0.2/s
91 Flushes         1.04k     0.0/s
92 Wait Free           0       0/s
93
94 __ InnoDB Lock _________________________________________________________
95 Waits               0       0/s
96 Current             0
97 Time acquiring
98   Total             0 ms
99   Average           0 ms
100  Max               0 ms
101
102 __ InnoDB Data, Pages, Rows ____________________________________________
103 Data
104   Reads           225     0.0/s
105   Writes          799     0.0/s
106   fsync           541     0.0/s
107   Pending
108     Reads           0
109     Writes          0
110     fsync           0
111
112 Pages
113   Created          23     0.0/s
114   Read            226     0.0/s
115   Written       1.04k     0.0/s
116
117 Rows
118   Deleted      25.04k     0.0/s
119   Inserted     25.04k     0.0/s
120   Read         81.91k     0.1/s
121   Updated           0       0/s

报表抬头：第1行

本行包括三部分信息：MySQL版本，MySQL运行时间，服务器当前时间。显示版本是为了提醒有些功能可能这台mysql没有；显示运行时间是为 了评估报表数据的精准度。事实上，如果一台mysql运行时间连几个小时都没有的，生成的很可能是一份扭曲并且充满误导意见的报表。甚至几个小时都不够， 因为它可能是在半夜没啥访问量的时候运行的几个小时。所以建议最少要运行过一个24小时，时间越长越能反应真实情况。 在本例中，运行时间只有34分钟，所以报表也不具有真实的代表意义。

索引报表：3-7行

索引报表是第一个主要章节，因为索引(key或者说index)对于mysql数据库，是最最最重要的。虽然报表不可能直接告诉你这个库的索引好还是不好，但它能告诉你这个索引缓冲区(key buffer)被利用的怎么样了。 注意：本报表仅汇总默认的MyISAM表的共享key buffer信息，而不会管管理员自建的其他空间。

缓冲区使用情况：第4行

对于mysql，我们的第一个问题就是：到底用了多少key buffer？如果不太多，没问题~因为mysql只会在有需求的时候才分配系统内存给key buffer。也就是说，my.cnf中定义了key_buffer_size=512M，不代表mysql启动时就创建一个512M大小的key buffer。

本行显示的，是mysql曾经使用过的key buffer峰值大小。而事实上，mysql应该用的更少，或者诡异的更多。这个更多的情况，mysql的术语叫“高水位”这个情况和my.cnf里的key_buffer_size是否足够大密切相关。当“水位”已经达到80-90%的时候，赶紧加大你的key_buffer_size吧。

注意：永远不用“担心”这个值超过95%，mysql文档指出，key buffer中的一部分会被mysql主程序用于内部数据结构，这些是mysqlreport无法统计的内容。所以，所谓的95%，其实已经是100%了……

当前情况：第5行

这行只有在mysql版本高于4.1.2时出现，因为之前mysql的show status中没有key_blocks_unused。这行数据显示的是mysql当前使用的key buffer大小。如果上行的used%太大的话，那么这行必然不会超过used，除非碰上那个传说中的bug了。综合这两行，相信对key_buffer_size的设置是否合理就有谱了~

本例中，mysql使用了60M的key buffer(12%)，这就很不错，离满负荷运行还早着呢。

写命中：第6行

从本质上说，索引是基于内存的。因为访问内存的速度比硬盘快太多了。不过，mysql从磁盘里进行一点点读写操作总是不可避免的。

这行数据显示了写索引的效率(具体意思是：写入磁盘的key与写入内存的key的比值)。这个值没有什么参考答案，而是取决于业务类型。如果 mysql主要执行的是update/insert之类的操作，那么正常比值接近0%；如果执行的select居多，那比值超过90%也是正常的。不过如 果你看到的是一个负数，那说明mysql总是在往那个慢的要死的磁盘里写索引，这就很不妙了。

要想知道到底比值正常与否，请参考之后的DMS报表内容。

读命中：第7行

比写命中重要多了的就是读命中。同样，这个值就是读自磁盘的key与读自内存的比值。这个比值最好别低于99%！！再低就有问题了——很可能就是key buffer太小。mysql没法从内存里读到，只好找硬盘了…… 当然，如果你刚重启过一次mysql，那在一两个小时内，命中率低一点也是正常的。

请求报表：9-26行

第二个主要章节。它展示了很多关于mysql在做什么以及做的怎么样的内容。请求(question)包括SQL查询(query)，也包括 mysql协议通讯。大家经常关注的一个性能是mysql的qps(每秒执行查询数)。不过从一个更广泛的眼光看来，这个衡量标准其实是很随意 的……mysql需要处理很多其他的请求。本报表试图展现的，就是这么一个更完整的内容。

总值：第10行

本行第一列，回答自运行起mysql一共处理多少请求，第二列，得出自运行起平均每秒钟处理多少请求。大家可能以为第二列这个值就是我们想要的qps了。但mysql真的做了这么多事情么？继续往下看。 （再次提醒大家注意questions和queries的区别）

查询的总体分布报表(DTQ)：第11-15行

所有的请求都可以被粗略的分入五类：数据操作语句(DMS)，查询缓存命中(QC Hits)，COM_QUIT，其他的COM_命令以及其他未知的东东。接下来的五行分别显示这些，从大到小排列。这样你可以一眼看出mysql最重要的 任务是什么了。一般的说，DMS和QCHits是主角，COM_是必须的，额，路人甲……

再详细解释每行之前，提示一下，第三列的比值分母是上面那行的总值。比如本例中DMS占到了82.84%就挺不错的。

DMS包括：select/insert/replace/update/delete(其他的比较偏门，mysqlreport干脆就排除他们了)。正常的说，mysql最应该做的事情，就是这些DMS了。详细内容见17-22行。

QC Hits是mysql从查询缓存里直接获取结果的数量。我们梦寐以求的就是让这个命中率变高，因为这意味着mysql响应变的相当快。但这也意味着你必须接受一定的数据差异性。详细理由见QC报表中的insert/prune和hit/insert比值部分。

在本例中QC Hits达到了16.91%，看来很不错的样子。可别被这么一条数据迷惑了，38-45行的QC报表会给你一个完全不一样的结论。

COM_QUIT，嗯，凑数的。

COM_，如果这个值比较高的话，或许会有些问题，详见23-26行。

Unknown，理想情况下，有上面四个类别就够了。因为有时候，mysql处理了几个请求，却没有记录相应的操作数。所以Unknown有+-两 种。+说明mysqlreport统计的多了，-就是少了。这个类别浮动性很大，某些特定情况下，可能会排名很靠前，不过最好还是在最底下吧。

慢查询：第16行

第16行非常重要，展示的是mysql执行的慢查询数。默认情况下，配置的long_query_time是10秒钟。事实上，大家都觉得这太长了，一般都改成1秒，甚至更短，mysql在版本5以后，支持到微妙us级别的。

配置的long_query_time会在’Slow’后面显示，默认8个字符，所以如果配置的是’9.999999 ms’，只会显示成’999.999 ‘，不过应该不会这么无聊吧~

理想情况下最好这里永远都是0，不过不太可能，多少还是有点。只要第三列的比例低于0.05%就行。

第四列，DMS中的slow比值；第五列，慢查询日志是否记录。强烈建议选择ON。

DMS：17-22行

和DTQ一样，第一行也是总值，其余内容也是动态排名。这部分内容可以解释mysql服务器偏重于什么类型：select还是insert，或者其 他。一般来说会是select吧。明确这个问题，对我们理解其他数值有很大的帮助。比如说：一个insert型的mysql，他的写比率接近1.0，同时 带来比较高的表锁。然后很可能用innodb表；一个select型的mysql则相反，读比率高，表锁少，而且很可能用的是MyISAM表。

本例就是一个select型的。65.72%的总请求是select(在DMS的比例提高到79.33%)，显然我们可以朝着select的方向进行优化了。

COM_：23-26行

这部分内容都很直观，在mysql协议里都有，像 com_change_db ，一眼就知道是干嘛的。

如果在DTQ排名里COM_比较高，那说明mysql忙着干自己的事情而不是响应SQL查询。比如说，如果一台mysql的 com_rollback 高，可能糟糕了，你的事物回滚失败了。结合之前的DTQ报表分析这个东西吧~ 一般这些东西不能出什么问题，不过时不时看一眼还是有必要的。

select/sort报表：28-36行

select和sort都是select_的内容。其中最主要的是29和31行：scan和full join。scan展示的是对全表进行扫描的select语句个数。full join和scan很像，除了它还出现于多表查询。程序联合多表进行全表扫描，听起来就慢的可怕……总之，对于这两个数值，只有更低，没有最低！

QC报表：38-45行

只有mysql版本支持QC并且my.cnf开启了QC的时候该报表才会出现。

内存使用：39行

如果内存使用的接近最大设置值，在更下面的Prune数据上也会有反应，因为QC里的查询会被踢出来。

内存碎片：40行

内存块碎片(block fragmnt)的详细解释参见《MYSQL手册》的5.14.3章节所述：

`query_cache_min_res_unit` 的默认值是4KB，大多数情况下足够用了。如果你有一个返回超小结果的海量查询，默认的块大小(即4KB)可能会导致大量的内存碎片，同样也浪费了很多空闲内存块。因为内存不足，碎片会强制删除(prune，我也不知道为啥不叫delete或者purge)QC里的部分内容。这时候你就得降低这个 `query_cache_min_res_unit` 设置。至于空闲块和QC的删除阀值，分别由 `Qcache_free_blocks` 和 `Qcache_lowmem_prunes` 定义。

内存碎片的计算方法是空闲内存块除以总内存块数。比值越大，碎片越多，10-20%就已经超出平均水平了。

本例的13.05%还是可以接受的，不过最好还是检查一下 query_cache_min_res_unit 是不是能调调~

Hits/Inserts/Prunes：41-43行

Hits是最重要的，它反映了select有多少是从QC里获得的应答，当然越多越好。至于insert和prune，或许从44行的比值中更好理解一下。之前有提到prune多说明qc太小，当然这只是一种可能而已。

本例中，只有55%的QC被利用，而碎片又不是太高。prune达到每秒16次，比QCHits高了一倍！打个不太恰当的（这话我加的，感觉比直接理解技术更难懂的比喻）比方：这台mysql的QC就像苹果树一样，苹果还没摘呢，树枝已经被砍掉了……

insert/prune和hit/insert比：44-45行

insert/prune是一个波动性的QC指标。一个稳定运行中的QC，insert进QC的查询数量应该大于prune掉的查询数量。而一个不 稳定的QC，比值或许是1:1，甚至偏向prune。这说明两个问题：1、QC大小不够；2、mysql试图缓存一切，结果帮了倒忙~

如果是第一种情况，简单的加大QC大小就够了。然后再观察碎片和内存使用率的情况。

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

mysql官方说明里这么解释这个type 1的：

“缓存一切查询结果，除非查询时使用'select sql_no_cache'方式”。

可惜这个 sql_no_cache 基本没人用。另一个稍微好一些的方式是 type 2 demand ，解释如下：

“只有在查询使用 `select sql_cache` 时才缓存查询结果”。

这个type对开发人员要求比较多，因为他们得明确指出哪些要缓存，哪些不要。不过也没人比他们更清楚到底哪些是该缓存的啦~

hit/insert用来反映QC的有效性。理想情况是：mysql插入一批稳定的查询到QC里，然后源源不断的命中这批结果……所以，如果QC的 有效性足够，这个比值应该是偏向hit的。如果不幸的偏向了insert，那说明QC其实没起到太大的作用。比如说1:1，一次insert用了一次 hit，然后就被替换了，这完全违背了使用QC的初衷。不过还有更糟的，比如0.34:1,一次都没用上，就被prune掉了……

本例的QCHits不低，hit/insert却不高。再考虑到内存使用和碎片情况也还可以。或许真的有必要换成type2的DEMAND了~~

表锁报表：47-49行

表锁报表包括两行，一行是总数，一行是当前数。锁等待对于数据库来说永远是糟糕的事情。第三列的总比值反应了一个综述的情况，无论如何不能高过10%，否则肯定就带来一大堆的索引和慢查询问题！

表报表：51-53行

也是两行，一行是当前mysql打开表的个数、表缓存的使用率，一行是mysql运行以来的平均值。

这里有两个值比较重要。一个是表缓存使用率，哪怕高到100%都行。不过要是真高到100%了，可能你的’table_cache’设置已经不够 了，赶紧加大吧。第二个是当前打开表的比率，这个也能协助判断’table_cache’设置是否合理。一般这个值应该小于每秒1次。不过一个负载比较高 而又运行的还不错的mysql，可能能达到每秒打开7次表，依然保持100%的表缓存~

连接数报表：55-57行

如果最大连接数曾经接近过100%，请加大’max_connection’设置。不过事实上，默认的100已经足够绝大多数哪怕相当繁忙的 mysql使用了，盲目加大这个设置其实不对。一个mysql链接持续1秒钟，100个就是足足100秒。所以如果连接数太高，或者说一直在慢慢涨，问题 很可能在别的地方，比如慢查询、糟糕的索引、甚至DNS解析太慢。在修改这个数的事情，还是先去研究一下为什么100个还不够呢？

至于每秒连接数，只要mysql运行正常，高低无所谓。不过大多数mysql这个值在每秒5次以下~~

临时表报表：59-62行

mysql可以在内存、磁盘甚至临时文件上创建临时表。这三种情况分别对应下面的三条报告。这些数据没有标准值，不过必须要知道的是磁盘上的临时表 示最慢的。mysql一般也避免在磁盘上创建临时表，除非达到了’tmp_table_size’的阀值。这个阀值会显示在内存(Table)那行的 Size列后面。至于内存和临时文件的数值到底该多少，取决于mysql数据库的硬件配置。

线程、中断、流量报表：64-76行

这三个报表是最重要的，系统级别的问题不用多说了都……

这里面有一个需要注意的地方：66行的线程命中率。每个mysql的连接都是一个单独的线程。mysql启动时，只创建不多的几个线程和一个线程缓存，以节省不断创建和销毁线程的开销，哪怕这个开销不怎么明显。当mysql的连接数超过了线程缓存数(由 thread_cache_size 定义)时，MySQL开始出现线程抖动(‘thread thrash’)。为了接纳新的连接，mysql疯狂的创建新线程，结果自然是线程命中率大幅下滑。

线程抖动是问题么？Yahoo的Jeremy Zawondy在博客中写了如下一段话：

所以上面这个故事的教训就是：如果你的服务器老是接受一些快速连接，想办法加大你的线程缓存吧，直到你的`show status`命令里`threads_created`不再飙升为止！你的CPU绝对会感谢你的。线程缓存不是啥大问题。可是你解决完真的大问题后，它就是最大的问题了……(汗)

所以，如果真出现线程抖动的话，加大’thread_cache_size’吧。

比如本例，线程缓存命中率只有可怜的0.05%！基本意味着每个连接都是新创建了线程。不过看看报表其他的内容，这也是必然的：缓存里一个线程都没有(66行)，201个线程被创建(67行),202个连接(57行)……

innodb缓冲池报表：78-92行

mysql版本5.0.2之后才在show status里加入了innodb_内容。所以这部分报表只在该版本之后有效。

innodb存储引擎的重要特性就是它把表数据和索引都缓存在缓冲池里。缓冲池内的页大小是16KB，可以包含各种不同的数据类型。本报表就展示了这些页的数值。

注：因为mysqlreport比较老，对innodb的采集分析不如myisam多。

使用率：79行

这个可以类比第4行的 key buffer used。不过myisam引擎只缓存索引，而innodb也存数据。所以要想知道这个使用率的详细情况，还得看81-85行的内容。

显然，必须避免mysql运行到缓冲池溢出的地步。myisam溢出，只会导致性能下降(索引读写变慢)，而innodb的溢出问题就多了，因为几乎所有东西都依赖缓冲池。所以最好还是配置好自增长缓冲池(‘auto-extending buffer pool’)吧。

读命中：80行

同样跟地7行的key read hit类似。不过对innodb来说这个数值更重要。缓冲池显示的是从内存读取的比例，所以一般都接近100%，绝大多数情况至少大于99.98%。

页：81-85行

各种各样的关于缓冲池中页的指标。比如82行的空闲页、83行的数据页、84行的杂页、85行的锁定页。

空闲页就是79行使用率的对立方。

数据页和空闲页一样是自描述的。我们没法知道这些页里有哪些数据类型。本行还有一列%Dirty，展示已经被修改过，但还没有被刷新到磁盘存储的数据页的比率。

另两样就更没什么可说的了。mysql手册上只是简单的这么描述这两样页：“用于管理分配行锁和自适应哈希索引导致的开销使用的页”和“目前正在读写、或者因为其他原因无法被刷新的页”。

读：86-89行

接下来的四行是关于innodb缓冲池的读情况的。86行是从内存读取的数量。在一个比较繁忙的innoDB引擎mysql服务器上，这个值应该非 常大，因为innodb总是试图从内存里的缓冲池读取页。这个数值可以用来衡量innodb缓冲池的吞吐量。因为几乎所有inondb需要的东西都是在缓 冲池里，所以缓冲池的读性能是越快越好。哪怕超过每秒200000次也不是不可能的。

87行的数值就小的多了。官方解释叫做“innodb无法从缓冲池获得而只能进行单页读取的逻辑读操作数”，其实就是从磁盘读的数量。

88行，随机读。官方解释“innodb启动的随机读取数。只有对表的大部分内容进行随机扫描的时候才会出现”。

89行，顺序读。官方解释“innodb启动的顺序读取数。只有进行全表扫描的时候才会出现”。全表扫描可不是什么好事，这个数值还是小点好。

写：90行

和86行类似，也可以用来衡量innodb的吞吐量。本行显示写的数量以及读写的比率。如果服务器主要操作是update和insert的话，这个值也会比较高。

刷新：91行

缓冲池的页刷新请求数。

空闲等待：92行

mysql手册上这么描述这个变量： 一般情况下，innodb缓冲池的写操作是后台运行的。不过，如果出现必须要读写一个页可偏偏没有可用的新页时，（innodb）就只能先等待页的刷新了。这个变量就是这些等待的总数。只要缓冲池的大小设置得当，等待数应该会很小。

innodb锁报表：94-100行

innodb的行锁变量是mysql5.0.3之后加入的。MyISAM引擎是表锁，而innoDB是行锁。所以当你使用innodb时这几个变量的值非常重要。

等待：95行

“等待某行解锁的累积次数”，最好是0次。

当前：96行

“当前正在等待解锁的行个数”，最好是0次。

时间分析：97-100行

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

innoDB数据、页、行报表：102-121行

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

数据：103-110行

第一部分，数据，列出了四种类型的操作：读、写、刷新(fsync)和等待(pending)。

1. 第一个类型：读，指的是整个innodb引擎完成所有的数据读取次数——注意：不是整个数据读取字节数或者类型，而是innodb完成的数据读取次数。
2. 第二个类型：写，和读一样也是次数的统计。
3. 第三个类型：刷新，同样的，innodb从内存写入磁盘的次数。这个值应该会比前两个小。
4. 第四个类型：等待，又被分成了三行(108-110)，分别是读、写、刷新的等待次数。

页：112-115行

这部分包括三种自描述类型：创建、读取、写入，分别用来表示缓冲池中页的创建、读取和写入的数量和速率(即每秒操作数)。由于没有指出具体是哪种页，这几个数值也就是用来概述一下innodb引擎的吞吐量罢了。

行：117-121行

最后一部分，行，只是一些比较泛泛的数值。包括对行的delete/insert/read/update操作。这些数值会比较大，而速率部分同样也是些概述参考……

结论

现在我们已经阅读甚至分析完了整个报表，可以对本例mysql做出一个总体的评价了。

总的来说，这个服务器运行情况还是不错的，几个关键指标都很好：key buffer只用了12%，DMS和QCHits占了请求的99%，也没有什么Com_问题，表锁也不错，表缓存只用了10%，连接数很低。

至于innodb引擎，服务器也在使用，但比重不大。目前这些innodb的状态变量反映出的情况看，一些正常。

不过还是有些优化的余地。首先一点，也是最重要的一点，就是查询缓存QC不太稳定；然后是线程缓存，建议调高 thread_cache_size，知道线程缓存命中率回升到满意值~~

 

转载自： http://chenlinux.com/2011/01/10/mysqlreport-guide/