mysql 知识 show status

mysql> show status;

Com_xxx 语句计数变量表示每个xxx 语句执行的次数。每类语句有一个状态变量。例如，Com_delete和Com_insert分别统计DELETE 和INSERT语句执行的次数。然而，如果一个查询的结果是从查询缓存中得到的，这会增加Qcache_hits，而不是Com_select

Connections                        4192

试图连接到(不管是否成功)MySQL服务器的连接数。

Created_tmp_disk_tables            0

服务器执行语句时在硬盘上自动创建的临时表的数量

Created_tmp_files                  5

mysqld创建的临时文件个数    

Created_tmp_tables                 1

服务器执行语句时在内存上自动创建的临时表的数量，如果Created_tmp_disk_tables较大，你可能要增加tmp_table_size值使临时 表基于内存而不基于硬盘。

Flush_commands                     1

flush的执行个数    

Handler_commit                     0     

Handler_delete                     0

从 表中delete行的次数，此参数与 Com_delete不一样，只要执行delete，Com_delete就会增加，而Handler_delete只有当在表中删除了行的时候才增加。 如果delete删除没有影响到表里的任何行，则不会增加Handler_delete值

Handler_discover                   0     

Handler_prepare                    0     

Handler_read_first                 0

索引中第一条被读的次数。这个表明。服务器正在进行全索引扫描 explain看的时候tpye类型为index    

Handler_read_key                   0

根据索引读行的次数，如果较高，说明查询使用了正确的表索引，explain看的时候tpye类型为const、eq_reg、ref、range、

Handler_read_next                  0

根据键顺序来读取下一行，如果你使用索引范围（range）或执行索引（index）扫描，该值增加，增加的大小为查出来的行数，一般order by 键值  该值增加 

Handler_read_prev                  0

根据键顺序来读取前一行， 基本上是用在ORDER BY ... DESC. 增加的大小为查出来的行数

Handler_read_rnd                   0

根据固定位置读一行的请求数，当需要对非键值排序时，该值会增加或者需要mysql扫描整个表时，该值会增加，增加的大小为查出来的行数 

Handler_read_rnd_next              0

在数据文件中读下一行的请求数，如果你正进行大量的表扫描，该值较高，并且增加的值为扫描的行数

(select  * from mrhao_order_info where address like '%AA%' order by address ，这个值会导致Handler_read_rn增加7，Handler_read_rnd_next 而这个会增加103840,

而select  * from mrhao_order_info where address like '%AA%' Handler_read_rnd_next 这个会增加103840，而Handler_read_rnd不会增加)

Handler_rollback                   0     

Handler_savepoint                  0     

Handler_savepoint_rollback         0     

Handler_update                     0     

Handler_write                      132

（以上handler同Handler_delete，只有影响了表里的任何行，才会增加该值）

Innodb_buffer_pool_pages_data      491   

Innodb_buffer_pool_pages_dirty     0     

Innodb_buffer_pool_pages_flushed   6050  

Innodb_buffer_pool_pages_free      0     

Innodb_buffer_pool_pages_latched   0     

Innodb_buffer_pool_pages_misc      21    

Innodb_buffer_pool_pages_total     512

data 包含数据的页数（脏或者干净的）dirty 当前的脏页数。flushed  刷新的页数 free 空页数

latched 锁定的页数（由于这个数据很号资源，所以UNIV_DEBUG 系统上编译使用） misc分配给行锁或者

hash索引管理用的页数 total 是总的页数 total=data+free+misc(5.4上 1页=16k)

Innodb_buffer_pool_read_ahead_rnd  3288  

Innodb_buffer_pool_read_ahead_seq  31840 

Innodb_buffer_pool_read_requests   3413220598

Innodb_buffer_pool_reads           104184

Innodb_buffer_pool_wait_free       0

Innodb_buffer_pool_write_requests  85786

read_ahead_rnd 表示在初始化innodb时，使用随机预读的个数，这个发生在对一个表有大量随机扫描的查询，read_ahead_seq 在初始化innodb时，使用顺序预读的个数，一般发生在全表顺序扫描，（innodb有两种预读模式：随机预读方式跟顺序预读 http://hi.baidu.com/fishhust/blog/item/7558f41083fdb808213f2efb.html/cmtid/71718e369bb4353a0b55a960  http://dev.mysql.com/doc/refman/5.0/en/innodb-disk-io.html）       read_requests 逻辑读请求的个数，reads 不在buffer pool 不得不从磁盘读取的逻辑请求个数，wait_free，一般情况下，在后台像innodb buffer pool写，然后，当需要读或者创建时，而又没有干净的页使用时，就需要等待页面刷新，这个状态就是等待实例进行计数， write_requests  为往buffer pool写入的个数

Innodb_data_fsyncs                 32146 

Innodb_data_pending_fsyncs         0     

Innodb_data_pending_reads          0     

Innodb_data_pending_writes         0     

Innodb_data_read                   1418334208

Innodb_data_reads                  146431

Innodb_data_writes                 34452 

Innodb_data_written                212622848

read 从服务器开启以来，innodb读取的字节数。reads 服务器读取的页数 ，written innodb写入的字节数 writes  服务器写入的页数（1页16K）fsyncs fsyncs（）操作数，pending_fsyncs 挂起的fsyncs（）操作数 pending_reads 挂起的读 pending_writes挂起的写

Innodb_dblwr_pages_written         6050  

Innodb_dblwr_writes                3324 

pages_written 双写操作已经写好的页数。  writes  已经执行的双写操作数量

Innodb_log_waits                   0     

Innodb_log_write_requests          2617  

Innodb_log_writes                  22335 

Innodb_os_log_fsyncs               25566 

Innodb_os_log_pending_fsyncs       0     

Innodb_os_log_pending_writes       0     

Innodb_os_log_written              12722176

Innodb_page_size                   16384 

Innodb_pages_created               13    

Innodb_pages_read                  610723

Innodb_pages_written               6050

size编译时，页的大小，一般为16K created 新建的页数 read  读的页数 written 写的页数

Innodb_row_lock_current_waits      0     

Innodb_row_lock_time               0     

Innodb_row_lock_time_avg           0     

Innodb_row_lock_time_max           0     

Innodb_row_lock_waits              0     

Innodb_rows_deleted                91    

Innodb_rows_inserted               824   

Innodb_rows_read                   1155270834

Innodb_rows_updated                337

deleted 删除的行数 inserted 插入的行数 read扫描时的行数（测试发现不是读取的行数） updated跟新的行数 以上数据只对innodb引擎，而com_ handler_是对所有引擎

Key_blocks_not_flushed             0     

Key_blocks_unused                  7150  

Key_blocks_used                    211   

Key_read_requests                  872516

Key_reads                          4553  

Key_write_requests                 7498  

Key_writes                         3768

Key_blocks_not_flushed  在 key cache中修改了，但是还没有刷新到磁盘上的块数，Key_blocks_unused     未使用的块数（key_buffer控制），

Key_blocks_used     使用的块数Key_read_requests  从cache中读取的请求数，Key_reads   从磁盘读取的块数，用Key_reads/Key_read_requests来计算cache的miss rate

Key_write_requests 写入cache的请求数，Key_writes  写入磁盘的块数

（注： 内存与磁盘交互的是块数，而cache的请求数为操作的行数。myisam 中data 与index是文件是分离的，当insert 数据的时候，myisam会直接插入数据到磁盘，但不会立即插入index到磁盘上，而是直接插入key_buffer中，而不刷新到磁盘上，所以有时候 Key_blocks_not_flushed 与Key_write_requests 可能会很高，但Key_writes 确很低，可用“flush table 表名” 强制刷新index到磁盘上。如果大量的块没有flush到磁盘上，若服务器这时候出现故障，myisam会在下次重启时，根据data文件重建 index文件，若没有重建成功，可用”repair table 表名“修理表   ）

Last_query_cost                    0.000000

查询优化器计算的最后编译的查询的总成本，这个在对于同一语句，来对比不同优化器很有用，默认为0，该变量为session变量

Max_used_connections               22  

服务器启动后，同时使用的连接的最大数量。

Not_flushed_delayed_rows           0

等待写入INSERT DELAY队列的行数

Open_files           

Open_streams

Open_table_definitions

Open_tables

Opened_files

Opened_table_definitions

Opened_tables

Open_files 打开文件的个数，这个统计是服务器打开的正规文件的个数。不包括socket 及pipe。当打开myisam表数据时，他会增加两个（数据文件与索引文件），当打开innodb表时，该值不增加，当打开的myisam表已另一个别 名打开时，Open_files只会增加一个。flush tables 会清空该值

Opened_files，当增加Open_files同时，他会已同样大小增加该值。当table_open_cache增加，或者flush tables 时，该值是不会减少，但也不增加的。

Open_table_definitions 打开表时被cache的frm文件个数。

Open_tables 打开表的个数。

Opened_table_definitions 与 Opened_tables 的解释与Opened_files差不多（跟网上说的只有当

table cache 到达table_open_cache时，才会增加Opened_files这值不一样哦）,以上状态有global 跟session

Prepared_stmt_count                0

当前prepared statements的个数，最大数会由变量max_prepared_stmt_count控制 ，当DEALLOCATE PREPARE时，改状态值会减小  

Qcache_free_blocks                 0     

Qcache_free_memory                 0     

Qcache_hits                        0     

Qcache_inserts                     0     

Qcache_lowmem_prunes               0     

Qcache_not_cached                  0     

Qcache_queries_in_cache            0     

Qcache_total_blocks                0

Qcache_total_blocks 显示了所有的块数(未使用的内存跟已使用),而Qcache_free_blocks 反映了未使用的块数。如果Qcache_free_blocks很大（如果没有内存碎片的话，应该为1），说明内存的碎片很多，内存的使用率会比较差，所 以这时虽然 Qcache_free_memory显示还有剩余的内存，也可能无法使用，当插入新的query时就需要清除旧的，使得 Qcache_lowmem_prunes很高。可以使用

flush query cache重整内存，操作之后Qcache_free_blocks应该为1，因为所有未使用的内存都放在一起作为连续的一块了  

Queries  

被服务器执行的语句个数，包括存储过程里的语句，也包括show status之类的  

Questions                          19483094

被服务器执行的语句个数， 但是不包括存储过程里面的语句

Rpl_status                         NULL  （暂时未使用）

Select_full_join                   0     

Select_full_range_join             0     

Select_range                       0     

Select_range_check                 0     

Select_scan                        1

有兴趣可以看看下面内容

http://hackmysql.com/selectandsort

在优化器explain中，显示的第一个表或者唯一的一个表他会影响： Select_scan and Select_range，

第二个表或子表会影响： Select_full_join, Select_range_check, and Select_full_range_join

show session status like "select%";的值会按照以下规则来增加

1；Select_scan 当顺序的从磁盘读取时，会增加该值，如explain中第一个表的type" 列显示ALL

EXPLAIN select * from t1,t2

2：Select_range 当explain中第一个表的type" 列显示range时，该值增加

EXPLAIN select * from t1,t2 where t1.c1>7800 and t1.c1<8000 and t1.c1=t2.c1

3：Select_full_join  explain当第二个表或子表的“type" 列显示ALL

EXPLAIN select * from t1,t2 where t1.c1>7800 and t1.c1<8000 and t1.c2=t2.c2

4：Select_full_range_join  explain的第二个表或子表为range时 该值增加

EXPLAIN select * from t1,t2 where t1.c1>7800 and t1.c1<8000 and t2.c1<1000 这个会增加Select_full_range_join 及Select_range

5：Select_range_check 的意思是不确定range的范围，

如：EXPLAIN select * from t2,t1 where t2.c1<t1.c2;第二个表显示：Range checked for each record (index map: 0x1)

Sort_merge_passes                  0     

Sort_range                         0     

Sort_rows                          0     

Sort_scan                          0

一般的，查询sort都会经历三个步骤

1.  查找where条件的值

2. 排序值

3. 读排序后的行

当在第一步时增加Select_scan, 则第三步就会是 增加Sort_scan. 如果第一步是增加 Select_range,则第三步就是 增加Sort_range.

Sort_merge_passes 包括两步。MySQL 首先会尝试在内存中做排序，使用的内存大小由系统变量 Sort_buffer_size 决定，如果它的大小不够把所有的记录都读到内存中，MySQL 就会把每次在内存中排序的结果存到临时文件中，这时候会增加Sort_merge_passes。等 MySQL 找到所有记录之后，再把临时文件中的记录做一次排序。实际上，MySQL 会用另一个临时文件来存再次排序的结果，所以通常会看到 Sort_merge_passes 增加的数值是建临时文件数的两倍。因为用到了临时文件，所以速度可能会比较慢，增加 Sort_buffer_size 会减少 Sort_merge_passes 和 创建临时文件的次数。但盲目的增加 Sort_buffer_size 并不一定能提高速度，

Slave_open_temp_tables             0     

Slave_retried_transactions         0     

Slave_running                      OFF   

Slow_launch_threads                0 

The number of threads that have taken more than slow_launch_time seconds to create.    

Slow_queries                       0     

The number of queries that have taken more than long_query_time seconds.

Table_locks_immediate              24364829

Table_locks_waited                 0     

Table_locks_immediate      立即获得的表的锁的次数。

Table_locks_waited         不能立即获得的表的锁的次数。

Threads_cached                     0     

Threads_connected                  12    

Threads_created                    4191  

Threads_running                    1  

Threads_cached        线程的缓存值，

Threads_connected     当前打开的连接的数量。

Threads_created       创建用来处理连接的线程数。如果Threads_created较大，你可能要增加thread_cache_size值。缓存访问率的计算方法 Threads_created（新建的线程）/Connections（只要有线程连接，该值就增加）。

Threads_running   激活的（非睡眠状态）线程数。

Uptime                             978671

The number of seconds that the server has been up. 

Uptime_since_flush_status          978671

The number of seconds since the most recent FLUSH STATUS statement（FLUSH STATUS,是把当前的session值加到global上,并重置key-cache及把Max_used_connections值变为当前的连接 数）.