mysql status另一则
http://blog.csdn.net/xjl1985/article/details/6210618
自己整理的mysql status字段信息
一） http://www.linuxidc.com/Linux/2007-12/10120p4.htm
SHOW INNODB STATUS
显示 InnoDB 存储引擎的状态
====================================================
aborted_clients 客户端非法中断连接次数
aborted_connects 连接 mysql 失败次数
com_xxx xxx 命令执行次数 , 有很多条
connections 连接 mysql 的数量
Created_tmp_disk_tables 在磁盘上创建的临时表
Created_tmp_tables 在内存里创建的临时表
Created_tmp_files 临时文件数
Key_read_requests The number of requests to read a key block from the cache
Key_reads The number of physical reads of a key block from disk
Max_used_connections 同时使用的连接数
Open_tables 开放的表
Open_files 开放的文件
Opened_tables 打开的表
Questions 提交到 server 的查询数
Sort_merge_passes 如果这个值很大 , 应该增加 my.cnf 中的 sort_buffer 值
Uptime 服务器已经工作的秒数
提升性能的建议 :
1. 如果 opened_tables 太大 , 应该把 my.cnf 中的 table_cache 变大
2. 如果 Key_reads 太大 , 则应该把 my.cnf 中 key_buffer_size 变大 . 可以用 Key_reads/Key_read_requests 计算出 cache 失败率
3. 如果 Handler_read_rnd 太大 , 则你写的 SQL 语句里很多查询都是要扫描整个表 , 而没有发挥键的作用
4. 如果 Threads_created 太大 , 就要增加 my.cnf 中 thread_cache_size 的值 . 可以用 Threads_created/Connections 计算 cache 命中率
5. 如果 Created_tmp_disk_tables 太大 , 就要增加 my.cnf 中 tmp_table_size 的值 , 用基于内存的临时表代替基于磁盘的
Aborted_clients 由於客��]有正�_�P�]�B接已�死掉，已�放��的�B接�盗俊�
Aborted_connects �L�已�失�〉� MySQL 伺服器的�B接的次�怠�
Connections ��D�B接 MySQL 伺服器的次�怠�
Created_tmp_tables ���绦姓Z句�r，已�被��造了的�[含�R�r表的�盗俊�
Delayed_insert_threads 正在使用的延�t插入�理器�绦芯w的�盗俊�
Delayed_writes 用 INSERT DELAYED ��入的行�怠�
Delayed_errors 用 INSERT DELAYED ��入的�l生某些�e�` ( 可能重�}�I值 ) 的行�怠�
Flush_commands �绦� FLUSH 命令的次�怠�
Handler_delete �求�囊��表中�h除行的次�怠�
Handler_read_first �求�x入表中第一行的次�怠�
Handler_read_key �求�底只�於�I�x行。
Handler_read_next �求�x入基於一���I的一行的次�怠�
Handler_read_rnd �求�x入基於一��固定位置的一行的次�怠�
Handler_update �求更新表中一行的次�怠�
Handler_write �求向表中插入一行的次�怠�
Key_blocks_used 用於�P�I字�存的�K的�盗俊�
Key_read_requests �求�木�存�x入一���I值的次�怠�
Key_reads �拇诺�物理�x入一���I值的次�怠�
Key_write_requests �求�⒁���P�I字�K��入�存次�怠�
Key_writes �⒁���I值�K物理��入磁碟的次�怠�
Max_used_connections 同�r使用的�B接的最大�的俊�
Not_flushed_key_blocks 在�I�存中已�改�但是��]被清空到磁碟上的�I�K。
Not_flushed_delayed_rows 在 INSERT DELAY �列中等待��入的行的�盗俊�
Open_tables 打�_表的�盗俊�
Open_files 打�_文件的�盗俊�
Open_streams 打�_流的�盗� ( 主要用於日�I��d）
Opened_tables 已�打�_的表的�盗俊�
Questions �l往伺服器的查�的�盗俊�
Slow_queries 要花超�^ long_query_time �r�g的查��盗俊�
Threads_connected ��前打�_的�B接的�盗俊�
Threads_running 不在睡眠的�绦芯w�盗俊�
Uptime 伺服器工作了多少秒。
�P於上面的一些注�：
如果 Opened_tables 太大，那�N你的 table_cache ��悼赡芴�小。
如果 key_reads 太大，那�N你的 key_cache 可能太小。�存命中率可以用 key_reads/key_read_requests �算。
如果 Handler_read_rnd 太大，那�N你很可能有大量的查�需要 MySQL �呙枵���表或你有�]正�_使用�I值的��Y (join) 。
#########################################################################################################################################
二） http://www.51testing.com/?110296/action_viewspace_itemid_69547.html
查看服务器目前状态信息的命令，两种方式：
1. 命令行，进入 mysql/bin 目录下，输入 mysqladmin extended-status
2. 连接到 mysql ，输入 show status;
3. 如果要查看某个数据，可以
mysql> show status like 'table%';
+-----------------------+-------+
| Variable_name | Value |
+-----------------------+-------+
| Table_locks_immediate | 12 |
| Table_locks_waited | 0 |
+-----------------------+-------+
需要关注的部分有：
qcache% ,open%tables,%key_read%,threads%, created_tmp%,sort%,com_select ， Handler%
这几个变量的调优参考“ mysql 服务器调优” http://www.ibm.com/developerworks/cn/linux/l-tune-lamp-3.html
状态变量详解，可能还有部分新的变量没列出来，
全部状态解释参看 mysql 手册 http://dev.mysql.com/doc/refman/5.0/en/server-status-variables.html （红色部分是调优的时候重点关注的变量）
Key_read_requests
引起从键的缓存读取键的数据块的请求的数量。 Key_reads 与 Key_read_requests 的比率不应该高于 1 ： 100 （也就是， 1 ： 10 很糟糕）
Key_reads
引起从磁盘读取键的数据块的物理读取操作的数量。
key_reads / key_read_requests 应该尽可能的低，至少是 1:100 ， 1:1000 更好
相关的一个 :Key_write<=Key_write_requests
Open_tables
目前打开的表的数量
Opened_tables
<1> 已经被打开的表的数量 ,( 注：表示附加打开的表文件描述符数量，详见 http://dev.mysql.com/doc/refman/5.0/en/table-cache.html ，结尾标注 1)
<2> 如果你发现 open_tables 等于 table_cache ，并且 opened_tables 在不断增长，那么你就需要增加 table_cache 的值了（上述状态值可以使用 SHOW STATUS LIKE ‘ Open%tables ’获得）。注意，不能盲目地把 table_cache 设置成很大的值。如果设置得太高，可能会造成文件描述符不足，从而造成性能不稳定或者连接失败。
<3> 通常结合 uptime 来观察，如果 Opened_tables 太大， uptime 太小，说明 table_cache 太小；如果 Opened_tables 不大，而 uptime 太大，说明不是 table_cache 的问题，有可能是其他原因导致 mysql 的处理任务繁重
<4>table_cache =max_connections*N (N: 每条 query 中需要打开的表的数目 )
相关的一个： Table_locks_waited ，，不能立即获得的表的锁的次数。如果该值较高，并且有性能问题，你应首先优化查询，然后拆分表或使用复制。如果增长速率过快，说明存在严重的表锁争夺（针对 myisam 的一个参数）
Qcache_inserts
添加到缓存中的查询的个数命中次数除以插入次数就是不中比率；用 1 减去这个值就是命中率
http://dev.mysql.com/tech-resources/articles/mysql-query-cache.html
Low ratios of hits to inserts indicate little query reuse or a too-low setting of the query_cache_limit, which serves to govern the RAM devoted to each individual query cache entry. Large query result sets will require larger settings of this variable.
Qcache_hits/Qcache_inserts 值较低，说明较少的 query 被重新利用或者 query_cache_limit 需要加大 ( 当有大的查询结果集的时候，如果 query_cache_limit 较小，则这个查询就不会被缓存 )
注：但是当 Qcache_queries_in_cache<<Qcache_inserts 时，表明你的缓存中的查询由于外面表的修改而失效，所以此时的缓存用处不大 ( 不需要加大 query_cache_limit)
Qcache_lowmem_prunes
缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看；如果这个数字在不断增长，就表示可能碎片非常严重，或者内存很少。（上面的 free_blocks 和 free_memory 可以告诉您属于哪种情况）。
注：当 flush query cache( 清理内存的 query cache) 运行花费太长时间，说明你的 query_cache_size 过大
Qcache_free_blocks
在查询缓存中空闲内存块的数量，数量大说明可能有碎片
Threads_created
如果该值持续增加，说明 thread_cache 有可能过小
Created_tmp_disk_tables
如果太大，表示 tmp_table_size 太小
(http://www.mysqlperformanceblog.com/2007/01/19/tmp_table_size-and-max_heap_table_size/)
注： tmp_table_size 和 max_heap_table_size 都可以控制临时表的最大大小， mysql 常驻内存的表的大小只有 max_heap_table_size 可以限制
sort_merge_passes
很大，就表示需要注意 sort_buffer_size 。例如， sort_buffer_size = 4M 将排序缓冲区设置为 4MB 。
更改 tmpdir 指向具有大量空闲空间的专用文件系统（路径应为位于不同物理 硬盘上的文件系统的目录，而不是同一硬盘的不同的分区。）
其它参数：
· Created_tmp_files
服务器执行语句时自动创建的内存中的临时表的数量。如果 Created_tmp_disk_tables 较大，你可能要增加 tmp_table_size 值使临时 表基于内存而不基于硬盘。
· Handler_read_rnd
根据固定位置读一行的请求数。如果你正执行大量查询并需要对结果进行排序该值较高。你可能使用了大量需要 MySQL 扫描整个表的查询或你的连接没有正确使用键。
· Handler_read_rnd_next
在数据文件中读下一行的请求数。如果你正进行大量的表扫描，该值较高。通常说明你的表索引不正确或写入的查询没有利用索引。
· Select_full_join
没有使用索引的联接的数量。如果该值不为 0, 你应仔细检查表的索引。
· Select_range_check
在每一行数据后对键值进行检查的不带键值的联接的数量。如果不为 0 ，你应仔细检查表的索引。
· Sort_merge_passes
排序算法已经执行的合并的数量。如果这个变量值较大，应考虑增加 sort_buffer_size 系统变量的值。
· Table_locks_waited
不能立即获得的表的锁的次数。如果该值较高，并且有性能问题，你应首先优化查询，然后拆分表或使用复制。
· Threads_created
创建用来处理连接的线程数。如果 Threads_created 较大，你可能要增加 thread_cache_size 值。缓存访问率的计算方法 Threads_created/Connections 。
· Handler_read_first
索引中第一条被读的次数。如果较高，它表明服务器正执行大量全索引扫描；例如， SELECT col1 FROM foo ，假定 col1 有索引。
· Handler_read_key
根据键读一行的请求数。如果较高，说明查询和表的索引正确。
· Handler_read_next
按照键顺序读下一行的请求数。如果你用范围约束或如果执行索引扫描来查询索引列，该值增加。
· Handler_read_prev
按照键顺序读前一行的请求数。该读方法主要用于优化 ORDER BY ... DESC 。
· Handler_read_rnd
根据固定位置读一行的请求数。如果你正执行大量查询并需要对结果进行排序该值较高。你可能使用了大量需要 MySQL 扫描整个表的查询或你的连接没有正确使用键。
· Handler_read_rnd_next
在数据文件中读下一行的请求数。如果你正进行大量的表扫描，该值较高。通常说明你的表索引不正确或写入的查询没有利用索引。
#########################################################################################################################################
三） http://blogs.techrepublic.com.com/opensource/?p=56
标题： Variable
What it represents
Why you should monitor it
1)Threads_connected
This variable indicates the total number of clients that have currently open connections to the server.
It provides real-time information on how many clients are currently connected to the server. This can help in traffic analysis or in deciding the best time for a server re-start.
2)Created_tmp_disk_tables
This variable indicates the number of temporary tables that have been created on disk instead of in-memory.
Accessing tables on disk is typically slower than accessing the same tables in memory. So queries that use the CREATE TEMPORARY TABLE syntax are likely to be slow when this value is high.
3)Handler_read_first
This variable indicates the number of times a table handler made a request to read the first row of a table index.
If MySQL is frequently accessing the first row of a table index, it suggests that it is performing a sequential scan of the entire index. This indicates that the corresponding table is not properly indexed.
5)Innodb_buffer_pool_wait_free
This variable indicates the number of times MySQL has to wait for memory pages to be flushed.
If this variable is high, it suggests that MySQL's memory buffer is incorrectly configured for the amount of writes the server is currently performing.
6)Key_reads
This variable indicates the number of filesystem accesses MySQL performed to fetch database indexes.
Performing filesystem reads for database indexes slows query performance. If this variable is high, it indicates that MySQL's key cache is overloaded and should be reconfigured.
7)Max_used_connections
This variable indicates the maximum number of connections MySQL has had open at the same time since the server was last restarted.
This value provides a benchmark to help you decide the maximum number of connections your server should support. It can also help in traffic analysis.
8)Open_tables
This variable indicates the number of tables that are currently open.
This value is best analyzed in combination with the size of the table cache. If this value is low and the table_cache value is high, it's probably safe to reduce the cache size without affecting performance. On the other hand, if this value is high and close to the table_cache value, there is benefit in increasing the size of the table cache.
9)Select_full_join
This variable indicates the number of full joins MySQL has performed to satisfy client queries.
A high value indicates that MySQL is being forced to perform full table joins (which are performance-intensive) instead of using indexes. This suggests a need for greater indexing of the corresponding tables.
10)Slow_queries
This variable indicates the number of queries that have taken longer than usual to execute.
A high value indicates that many queries are not being optimally executed. A necessary next step would be to examine the slow query log and identify these slow queries for optimization.
11)Uptime
This variable indicates the number of seconds since the server was last restarted.
This value is useful to analyze server uptime, as well as to generate reports on overall system performance. A consistent low value indicates that the server is being frequently restarted, thereby causing frequent interruptions to client service.
标注 1 ：
【 Posted by Richard Bronosky on April 21 2008 4:58pm [Delete] [Edit] 】
I think it is unclear what the difference between Open_tables and Opened_tables are. I will explain as I understand it, and I hope I will be corrected where I may be inaccurate.
Open_tables is a status variable indicating the number of file descriptors that are currently open by all running threads. When multiple threads access a single table simultaneously, multiple file descriptors are used. This makes it possible, and likely, that Open_tables exceeds the number of tables (SELECT COUNT(*) FROM information_schema.TABLES;) on your instance.
table_cache is a system variable the defines the number of file_descriptors that are allocated into a pool to be used for Open_tables as needed. When the MySQL threads need to open "greater than table_cache" number of tables, additional file descriptors are opened. Each time one of these additional file descriptors is opened, the status variable Opened_tables is incremented.
Opened_tables is a status variable that keeps a running tally of the number of additional file descriptors that have been allocated for opening tables at times when the available file descriptors in table_cache have been depleted. These files descriptors are released when demand subsides. There is no way of knowing what the maximum number used descriptors has been over time since the variable Opened_tables is the tally since the instance's Uptime.
It is not uncommon to see a value of 0 for Opened_tables. This simply means that the table_cache has never been exceeded.
Example :
> show status like 'Open%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Open_files | 487 |
| Open_streams | 0 |
| Open_tables | 325 |
| Opened_tables | 0 |
+---------------+-------+
4 rows in set (0.01 sec)
> select @@table_cache;
+---------------+
| @@table_cache |
+---------------+
| 512 |
+---------------+
1 row in set (0.02 sec)
【 Posted by Horst Pralow on May 19 2008 9:21am [Delete] [Edit] 】
The status variable 'Opened_tables' will also be incremented by 2 each time you create a temporary table.
Thus if you are using temporary tables, a large value in the global status varaiable 'Opened_tables' does not necessarily indicate that your table_cache value is too small, and increasing table_cache will not stop