最近看了看mysql的状态变量,感觉好多跟以前自己想象的不一样。为了以后能及时发现自己的错误,就先记下来;
http://dev.mysql.com/doc/refman/5.1/en/server-status-variables.html mysql> show status; Binlog_cache_disk_use 0 Binlog_cache_use 5732727 Binlog_cache_use表示有多少个事物使用了binlog_cache_size来缓存未提交的事物日志。 Binlog_cache_disk_use 当事务日志比binlog_cache_size大时,他会创建临时文件,该状态表示有多少个事务使用了临时文件 以上两个参数可以用来动态调整binlog_cache_size变量,并且以上两个值只有在启动log-bin日志时才会有变化 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值变为当前的连接 数). |
mysql状态 status
最新推荐文章于 2024-07-16 21:32:20 发布