mysql的会话变量,全局变量,状态信息

    mysql数据库系统自定义的参数和系统的运行参数都非常重要，他们决定了数据库运行的方式。例如是否自动提交，事务隔离级别这些变量。我们可以通过修改系统的会话变量和全局变量来影响数据库运行（其中有些变量修改需要修改重启才能生效）。。。。。。变量设置是过程，我们最终目的是要看状态（见下图），查看数据库状态信息是否符合要求。

    mysql变量分为会话级别和全局级别：用户变量和会话级别的系统变量属于会话级别的变量；而系统变量中的全局变量属于全局级别的变量。当然喜欢的话也可以按照用户变量和系统变量这个角度来划分变量。

    而系统变量按其作用域的不同分为以下几种：

 

1）分为全局（GLOBAL）级：对整个MySQL服务器有效

SELECT @@GLOBAL.autocommit

SHOW GLOBAL VARIABLES LIKE 'autocommit'

 

2）会话（SESSION或LOCAL）级：只影响当前会话

SELECT @@SESSION.var_name 或 

SELECT @@LOCAL.var_name 

SHOW SESSION  VARIABLES LIKE 'autocommit'

 

3）both，即是全局变量也是会话变量

上面既有全局变量autocommit，也有会话变量的autocommit。

但是规定如果没有在前面声明SESSION还是GLOBAL，优先显示会话级别的值。

     

1会话级变量

      什么是会话级别呢？比如我这里用msyql客户端工具创建了2个查询分析器，就是2个会话。可以认为一个会话就是一个线程连接。线程之间互不影响。

        会话变量包含了用户变量和session变量。特点是线程之间互不影响，且当连接断开变量消失

 

1.1用户自定义变量

        用户变量当然是会话级别的，但是也分为两种：1.存储过程中的变量，只存活在存储过程中；2.利用sql语句将值存储在用户自定义变量中。

    1.11.存储过程中的变量

      存储过程指的是一组可编程的函数，是为了完成特定功能的SQL语句集，经编译创建并保存在数据库中，用户可通过指定存储过程的名字并给定参数(需要时)来调用执行。  相对于oracle数据库来说，MySQL的存储过程相对功能较弱，使用较少。

    

mysql> delimiter //　　#将语句的结束符号从分号;临时改为两个$$(可以是自定义)
mysql> CREATE PROCEDURE delete_matches(IN p_playerno INTEGER)
    -> BEGIN
    -> 　　DELETE FROM MATCHES
    ->    WHERE playerno = p_playerno;
    -> END; //
Query OK, 0 rows affected (0.01 sec)

mysql> delimiter ;　　#将语句的结束符号恢复为分号

• 默认情况下，mysql中的delimiter（分隔符）是分号;。在命令行客户端中，如果有一行命令以分号结束，那么回车后，mysql将会执行该命令。当输入“delimiter //”这是告诉mysql不要以分号作为马上执行的标记，而是用//这个符号。最后再告诉mysql用回分号作为分隔符。

 

       1.1.2 储存sql的值

# 实例说明：

1. declare @name nvarchar(10),@id int  
2. set @name='张三'  
3. set @int=1  
4. update set name=@name from student where id=@id 

mysql> SELECT 'Hello World' into @x;

mysql> SELECT @x;

mysql> SET @y='Goodbye Cruel World';

mysql> select @y;

mysql> SET @z=1+2+3;

mysql> select @z;

 

1.2会话变量

这里的会话级别变量指的是系统设置会话的变量。属于系统变量。

SHOW SESSION VARIABLES

共有452个变量。可见可以影响会话的系统变量很多。

查看当前用户信息

--查看当前用户

SELECT USER() 

--查看当前的数据库

SELECT DATABASE()

--查看当前用户的权限

SHOW GRANTS FOR root@127.0.0.1

 

1.2.1 用于连接的会话变量

--查看同一账户的所有客户端允许连接到mysql的最大并行连接数

show global status like 'max_user_connections';

如果设置为0表示不限制。但是这个值需要严格控制。

 

1.2.2 临时表使用内存

--查看临时表使用的内存（线程）

show variables where Variable_name in ('tmp_table_size', 'max_heap_table_size'); 

max_heap_table_size    16777216

tmp_table_size    16777216

重点：一般这两个值都是相等的。意思是当临时表的大小超过了这个值就将会放置到硬盘中去。

--超过限制的临时表存放硬盘地址

show variables like 'tmpdir';

解释：

    tmp_table_size它规定了内部内存临时表的最大值，每个线程都要分配。（实际起限制作用的是tmp_table_size和max_heap_table_size的最小值。）如果内存临时表超出了该值的限制，MySQL就会自动地把它转化为基于磁盘的MyISAM表，存储在指定的tmpdir目录下

先看看mysql的内存组成，看看哪些是GLOBAL哪些是SESSION

used_Mem =

+ key_buffer_size

+ query_cache_size

+ innodb_buffer_pool_size

+ innodb_additional_mem_pool_size

+ innodb_log_buffer_size

 

+ max_connections *(

    + read_buffer_size

    + read_rnd_buffer_size

    + sort_buffer_size

    + join_buffer_size

    + binlog_cache_size

    + thread_stack

    + tmp_table_size

    + bulk_insert_buffer_size

)

可以看出max_connections后面这些变量值都属于会话级别的变量。

举例：SHOW SESSION VARIABLES LIKE 'bulk_insert_buffer_size'

 

2.全局变量

    如何了解一个数据库，当然需要从变量来了解。数据库不仅仅是个表格，它把所有表格数据和元数据也都存在在数据库中。都可以通过查询得到：当然还有很多数据库的信息必须通过元数据的查询来得到。这里我们用的最多的就是information_schema，performance_schema，mysql三个数据库。

    我们尝试着通过查询系统变量和数据库元数据表来得到数据库的基本信息。

--先看数据库的版本和主目录：

SHOW GLOBAL VARIABLES LIKE 'VERSION%'   # 查看数据库的版本号和系统版本

SHOW GLOBAL VARIABLES LIKE '%dir%'   # 查看数据库的目录

--查看数据库有哪些用户；有哪些数据库；有哪些表格，

SELECT DISTINCT User FROM mysql.user;    # 查看所有的用户

SHOW DATABASES;  #查看所有的数据库

SHOW TABLES;   #查看当前数据库下所有的表格

--查看数据库是否区分大小写

show GLOBAL variables like 'lower_case_table_names';

解释：lower_case_table_names： 此参数不可以动态修改，必须重启数据库
lower_case_table_names = 1  表名存储在磁盘是小写的，但是比较的时候是不区分大小写
lower_case_table_names=0  表名存储为给定的大小和比较是区分大小写的 
lower_case_table_names=2, 表名存储为给定的大小写但是比较的时候是小写的

 

2.1 用于连接的全局变量

 

--查看最大允许的最大连接(MYSQL服务能够同时接受的最大并行连接数)

show global variables like 'max_connections';

--查看针对某一个IP主机连接中断与mysql服务连接的次数，如果超过这个值，这个IP主机将会阻止从这个IP主机发送出去的连接请求。如果需要重新连接需要执行flush hosts

SHOW  GLOBAL VARIABLES like 'max_connect_errors';

 

 

2.2 查看innodb设置参数

--查看innodb的缓冲池大小（相当于oracleSGA。非常影响性能）

SHOW VARIABLES like 'innodb_buffer_pool_size'

该值默认为128M。如果是主要用作innodb数据库服务器，根据实际情况应占物理内存的60-75%

--查看innodb的额外内存池（存放数据字典信息和内部数据结构，通常打开的表比较多的可以适当增大。基本16M够用）

SHOW  VARIABLES like 'innodb_additional_mem_pool_size%'

 

--查看缓冲池中脏页的比例（保持一定比例以保证有空白页）

SHOW  VARIABLES like 'innodb_max_dirty_pages_pct%'

 

2.3 查看binlog设置参数

 

SHOW GLOBAL VARIABLES like 'binlog%'

binlog_cache_size    32768
binlog_checksum    CRC32
binlog_direct_non_transactional_updates    OFF
binlog_error_action    IGNORE_ERROR
binlog_format    STATEMENT
binlog_gtid_simple_recovery    OFF
binlog_max_flush_queue_time    0
binlog_order_commits    ON
binlog_row_image    FULL
binlog_rows_query_log_events    OFF
binlog_stmt_cache_size    32768
binlogging_impossible_mode    IGNORE_ERROR
 

--查看单个的二进制文件的大小

show variables like '%max_binlog%';

max_binlog_cache_size    18446744073709547520
max_binlog_size    1073741824
max_binlog_stmt_cache_size    18446744073709547520

 

--查看二进制文件的大小

show GLOBAL VARIABLES like 'max_binlog_size';

    max_binlog_size该参数指定了单个二进制日志文件的最大值，如果超过该值，则产生新的二进制日志文件，后缀名+1，并记录到.index文件

 

SHOW GLOBAL VARIABLES like 'Binlog_format%'

Binlog_format参数也特别重要。

mysql复制主要有三种方式：基于SQL语句的复制(statement-based replication, SBR)，基于行的复制(row-based replication, RBR)，混合模式复制(mixed-based replication, MBR)。对应的，binlog的格式也有三种：STATEMENT，ROW，MIXED。

① STATEMENT模式（SBR）

每一条会修改数据的sql语句会记录到binlog中。优点是并不需要记录每一条sql语句和每一行的数据变化，减少了binlog日志量，节约IO，提高性能。缺点是在某些情况下会导致master-slave中的数据不一致(如sleep()函数， last_insert_id()，以及user-defined functions(udf)等会出现问题)

② ROW模式（RBR）

不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了，修改成什么样了。而且不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题。缺点是会产生大量的日志，尤其是alter table的时候会让日志暴涨。

③ MIXED模式（MBR）

以上两种模式的混合使用，一般的复制使用STATEMENT模式保存binlog，对于STATEMENT模式无法复制的操作使用ROW模式保存binlog，MySQL会根据执行的SQL语句选择日志保存方式。

 

2.4 查看连接超时的设置

 

--查看服务器强制关闭后需要等待时间：

show global VARIABLES  like 'interactive_timeout%'

 

--查看客户端和服务器端在无交互状态从而被服务器强制关闭需要等待的时间

show global VARIABLES  like 'wait_timeout%';

 

 

3.状态信息

      数据库的参数设置（变量设置）和状态信息是两回事！前面的变量设置是你根据硬件来调整mysql数据库的细节运行方式。而状态信息则表现了数据库在你的参数设置下是否能够运行的情况。你可以根据状态信息的反馈来继续调整你的数据库运行方式。

3.1普通状态信息

--查看全部状态信息

SHOW STATUS

--查看当前mysql本次启动后的运行统计时间

SHOW STATUS LIKE 'uptime'

 

3.2 查看DML的执行数量

--查看select语句的执行数

show [global] status like 'com_select';

--查看insert语句的执行数

show [global] status like 'com_insert';

--查看update语句的执行数

show [global] status like 'com_update';

--查看delete语句的执行数

show [global] status like 'com_delete';

 

3.3 查看连接

    ”mysql: error 1040: too many connections”出现的原因：一种是访问量确实很高，mysql服务器抗不住，这个时候就要考虑增加从服务器分散读压力，另外一种情况是mysql配置文件中max_connections值过小：

--查看试图连接到MySQL(不管是否连接成功)的连接数

show status like 'connections';

--查看服务器相应的最大连接数（它是指从这次mysql服务启动到现在，同一时刻并行连接数的最大值）

show global status like 'max_used_connections';

--查看连接失败的连接数

show global status like 'Aborted_connects';

参数说明：

1.如果一个客户端在成功连接之后，不正常中断或结束，Aborted_connects将会增加1。并会将日志记录到error日志里。（log_warning设置为2才会记录）；

产生原因：客户端在退出会话之前没有调用mysql_close();客户端睡眠时间超过wait_timeout或者interactive_timeout的值；客户端在传输数据过程中突然结束。

2.如果一个客户端没有成功连接，Aborted_connects也会增加1（不会记录日志）

产生原因：客户端没有权限；客户端用户密码错误；连接包没有包含正确的信息；连接时间超过connect_timeout

如果Aborted_connects不断增加，可能有人在试图破坏你的服务器，这时可以打开generallog查看更多的信息

可能发生的原因：max_allowed_packet设置太小或者客户端查询要求更大内存；以太网协议漏洞；线程池有问题；tcp/ip配置不好；以太网、交换机、网线等硬件配置出现错误

解释：一般来说，Max_used_connections / max_connections * 100% ≈ 85%。

 

 

3.4 查看线程的状态

--查看所有的线程

show full processlist;

--查看线程信息

SHOW STATUS LIKE'Threads%';

--查看线程缓存内的线程的数量。

show status like 'threads_cached';

--查看当前打开的连接的数量。

show status like 'threads_connected';

--查看创建用来处理连接的线程数。如果Threads_created较大，你可能要增加thread_cache_size值。

show status like 'threads_created';

--查看激活的(非睡眠状态)线程数。

show status like 'threads_running';

 

#Threads_cached :代表当前此时此刻线程缓存中有多少空闲线程。
#Threads_connected :代表当前已建立连接的数量，因为一个连接就需要一个线程，所以也可以看成当前被使用的线程数。
#Threads_created :代表从最近一次服务启动，已创建线程的数量。
#Threads_running :代表当前激活的（非睡眠状态）线程数。并不是代表正在使用的线程数，有时候连接已建立，但是连接处于sleep状态，这里相对应的线程也是sleep状态。

--查看创建时间超过slow_launch_time秒的线程数。

show status like 'slow_launch_threads';

--查看查询时间超过long_query_time秒的查询的个数。

show status like 'slow_queries';

--查看已经放弃的clients或者链接

show status like 'Aborted_%'

 

3.5查看事务隔离级别

--查看数据库的事务隔离级别

SHOW GLOBAL VARIABLES LIKE 'tx_isolation%';

事务隔离级别	脏读	不可重复读	幻读
读未提交（read-uncommitted）	是	是	是
不可重复读（read-committed）	否	是	是
可重复读（repeatable-read）	否	否	是
串行化（serializable）	否	否	否

在不同的事务隔离级别，在不同的索引条件下，进行当前读的时候表格锁定的范围是不同的。具体在这里不展开说明。

特别要介绍的是间隙锁（gap lock），它只会出现在可重复读或者这个级别之上。当前读上面存在一般索引的情况下（非主键索引和唯一索引），当前读操作的范围都会被锁定而不能进行insert操作和update操作。

3.6 查看打开文件和表格

        MyISAM和CSV表打开时占用2个文件描述符，Innodb则需要1个文件描述符。一些日志信息（relay log，binlog，error-log等）也需要文件描述符。table_open_cache对MyISAM有效，对Innodb无效。当运行 flush tables 关闭表的时候，只对MyISAM表有效，即关闭有MISAM表的文件描述符，Innodb表也会关闭，但是文件描述符不会关。
       当表都是MyISAM，在极端的情况下，table_open_cache数目的表全部被打开（512张）就会占用掉1024个文件描述符。而open_files_limit是1024的话，就会出现报错的情况(本文例子的情况)。所以如果是有大量的 MyISAM 表，那么就需要特别注意打开文件数是否会超出限制了。

linux系统中输入：
cat /proc/26288/limits     
ls -lh /proc/26288/fd | wc -l   #mysql打开的文件描述符数量

3.6.1修改OS以及mysql的打开文件限制：

Linux会为每个用户登录系统打开最大文件数都有限制, 这个限制通过 ulimit -n 可以看到, 一般是 1024 .

第一步，修改/etc/security/limits.conf文件，在文件中添加如下行：
　　speng soft nofile 10240
　　speng hard nofile 10240
　　其中speng指定了要修改哪个用户的打开文件数限制，可用'*'号表示修改所有用户的限制；soft或hard指定要修改软限制还是硬限制；10240则指定了想要修改的新的限制值，即最大打开文件数(请注意软限制值要小于或等于硬限制)。修改完后保存文件。

　　第二步，修改/etc/pam.d/login文件，在文件中添加如下行：
　　session required /lib/security/pam_limits.so
　　这是告诉Linux在用户完成系统登录后，应该调用pam_limits.so模块来设置系统对该用户可使用的各种资源数量的最大限制(包括用户可打开的最大文件数限制)，而pam_limits.so模块就会从/etc/security/limits.conf文件中读取配置来设置这些限制值。修改完后保存此文件。
　　第三步，查看Linux系统级的最大打开文件数限制，使用如下命令：
　　[speng@as4 ~]$ cat /proc/sys/fs/file-max
　　12158
　　这表明这台Linux系统最多允许同时打开(即包含所有用户打开文件数总和)12158个文件，是Linux系统级硬限制，所有用户级的打开文件数限制都不应超过这个数值。通常这个系统级硬限制是Linux系统在启动时根据系统硬件资源状况计算出来的最佳的最大同时打开文件数限制，如果没有特殊需要，不应该修改此限制，除非想为用户级打开文件数限制设置超过此限制的值。修改此硬限制的方法是修改/etc/rc.local脚本，在脚本中添加如下行：
　　echo 22158 > /proc/sys/fs/file-max
　　这是让Linux在启动完成后强行将系统级打开文件数硬限制设置为22158。修改完后保存此文件。

然后在mysql的配置文件中进行修改：

修改 my.cnf 限制

open_files_limit =10240
innodb_open_files=10240

重启 mysql

show global variables like '%open%';

| open_files_limit | 10240

3.6.2 mysql中打开文件的表格关系

查看打开文件情况

mysql>show global status like 'open%';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| Open_files               | 804   |
| Open_streams             | 0     |
| Open_table_definitions   | 400   |
| Open_tables              | 400   |
| Opened_files             | 6803  |
| Opened_table_definitions | 3861  |
| Opened_tables            | 4315  |
+--------------------------+-------+
rows in set (0.00 sec)

mysql>show global variables like 'open%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| open_files_limit | 2000  |
+------------------+-------+
row in set (0.00 sec)

mysql>show global variables like 'table_open_cache';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| table_open_cache | 400   |
+------------------+-------+
row in set (0.00 sec)

Open_table_definitions  ：代表当前缓存了多少.frm文件。
Opened_table_definitions：代表自从MySQL启动后，缓存了.frm文件的数量。 需要注意的是.frm文件是MySQL用于存放表结构的文件，对应myisam和innodb存储引擎都必须有的，可以通过show open tables 查看 这2个变量的值。

      table_open_cache指定表高速缓存的大小（这个参数表示针对所有threads的table cache总和）每当MySQL访问一个表时，如果在表缓冲区中还有空间，该表就被打开并放入其中，这样可以更快地访问表内容。
      通过检查峰值时间的状态值Open_tables和Opened_tables，可以决定是否需要增加table_open_cache的值。
如果你发现open_tables等于table_open_cache，并且opened_tables在不断增长，那么你就需要增加table_open_cache的值了(上述状态值可通过SHOW GLOBAL STATUS LIKE ‘Open%tables’获得)。

其中open_tables表示当前打开的table总和，即所有connection打开的table总数。

opened_tables表示打开过的表的数量总和，只有show global status才能看到它的值。

      看上面的范例，open_tables达到了最大值400（table_open_cache值），但是opened_tables达到了6803个。表示文件在不断打开但是因为达到上限系统不能同时打开更多表格。那么你就需要增加table_open_cache的值！

      把MySQL数据库放在生产环境中试运行一段时间，然后把参数的值调整得比Opened_tables的数值大一些，并且保证在比较高负载的极端条件下依然比Opened_tables略大。

 

3.7 查看innodb的运行信息

    innodb存储引擎内存由以下三个部分组成：缓冲池(buffer pool),重做日志缓存(redo log buffer),额外的内存池(additional memory pool)。

    可以使用 show engine innodb status来查看innodb_buffer_pool的使用情况。

    innodb_buffer_pool_size：具体看，缓冲池中的数据库类型有：索引页、数据库页、undo页、插入缓存页(insert buffer)、自适应hash(adaptive hashindex)、innodb存储的锁信息(lock info)、数据字典信息(data dictionary)。

    InnoDB工作方式：将数据文件按页(每页16K)读入InnoDBbuffer pool，然后按最近最少使用算法(LRU)保留缓存数据，最后通过一定频率将脏页刷新到文件。

    被InnoDB存储引擎管理的两个重要的基于磁盘的资源是InnoDB表空间数据文件和它的日志文件。

3.7.1 缓冲池的状态

--查看innodb的数据页的大小。一般默认为16K

show global status like 'Innodb_page_size';

--查看缓存池中总的数据页数量

show global status like 'Innodb_buffer_pool_pages_total';

--查看缓存池汇中存有数据的数据页（包括dirty andclean pages）

show global status like 'Innodb_buffer_pool_pages_data';

    解释：根据Innodb_buffer_pool_pages_data / Innodb_buffer_pool_pages_total * 100%这个值判断在缓冲池中到底用到了多少数据页。一般这个数值控制在95%左右。

show status like  'Innodb_buffer_pool_%';

+-----------------------------------+-------+

| Variable_name    | Value |

+-----------------------------------+-------+

|Innodb_buffer_pool_read_ahead_evicted  | not started | 
|Innodb_buffer_pool_load_status|  not started |

| Innodb_buffer_pool_pages_data     | 70    |
| Innodb_buffer_pool_pages_dirty    | 0    |

| Innodb_buffer_pool_pages_flushed | 0    |

| Innodb_buffer_pool_pages_free    | 1978    |

| Innodb_buffer_pool_pages_latched | 0    |

| Innodb_buffer_pool_pages_misc     | 0    |

| Innodb_buffer_pool_pages_total    | 2048    |

| Innodb_buffer_pool_read_ahead_rnd  | 1    |

| Innodb_buffer_pool_read_ahead_seq  | 0    |

| Innodb_buffer_pool_read_requests | 329    |

| Innodb_buffer_pool_reads    | 19    |

| Innodb_buffer_pool_wait_free    | 0    |

| Innodb_buffer_pool_write_requests | 0    |

+-----------------------------------+-------+

 

3.8 查看数据库中表中的锁定

      这些状态参数只能知道数据库运行期间出现表锁和行锁的发生次数。在information_schema下面有三张表:INNODB_TRX、INNODB_LOCKS、INNODB_LOCK_WAITS，通过这三张表，可以更简单地监控当前的事务并分析可能存在的问题。

--查看表级别的锁定

show status like 'table%'

Table_locks_immediate    76     --产生表级锁定的次数；当然需要知道select页会产生表的共享锁
Table_locks_waited    0          --出现表级锁定争用而发生等待的次数
Table_open_cache_hits    0
Table_open_cache_misses    0
Table_open_cache_overflows    0

--查看innodb的行级锁定

show status like 'innodb_row_lock%'; 

 Innodb_row_lock_current_waits：当前正在等待锁定的数量；
Innodb_row_lock_time ：从系统启动到现在锁定的总时间长度；
Innodb_row_lock_time_avg ：每次等待所花平均时间；
Innodb_row_lock_time_max：从系统启动到现在等待最长的一次所花的时间；
Innodb_row_lock_waits ：从系统启动到现在总共等待的次数。

--查看立即获得的表的锁的次数。

show status like 'table_locks_immediate';

--查看不能立即获得的表的锁的次数。如果该值较高，并且有性能问题，你应首先优化查询，然后拆分表或使用复制。

show status like 'table_locks_waited';

--查看正在使用的表，并联合processlist找出目标的id

SHOW OPEN TABLES LIKE 'ta%'
SHOW OPEN TABLES FROM sockets

SHOW OPEN TABLES WHERE in_use >=1;  #找出争用的表格

以后会专门讲解如何定位表锁。

3.9 查看存储过程

--查看数据库中所有的存储过程：

show procedure status

show create procedure sp_name

 

3.10 查看临时表

     mysql内部存在两种临时表，一种是heap临时表，这种表数据都存在在内存中没有io操作；另一种临时表是ondisk临时表。只有当临时表数据大于max_heap_table_size的时候，heap临时表将自动转换为ondisk临时表。可想而知ondisk是及其影响数据库性能的。

show global status like 'created_tmp%'; 

Created_tmp_disk_tables    3     
Created_tmp_files    5
Created_tmp_tables    44

    每次创建临时表，Created_tmp_tables增加，如果是在磁盘上创建临时表，Created_tmp_disk_tables也增加,Created_tmp_files表示MySQL服务创建的临时文件文件数。

 

3.11 查看myisam表索引cache命中率

 

    key buffer 命中率代表了myisam类型表的索引cache命中率，命中率的大小直接影响myisam类型表的读写性能。key buffer 命中率实际上包括读命中率和写命中率两种，mysql中并没有直接给出这两个命中率的值，但是可以通过如下方式计算：

key_buffer_read_hits=(1-key_reads/key_read_requests) * 100%

key_buffer_write_hits=(1-key_writes/key-write-requests)*100%

show status like 'key%'

Key_blocks_not_flushed    0
Key_blocks_unused    7171
Key_blocks_used    2
Key_read_requests    14
Key_reads    2
Key_write_requests    0
Key_writes    0
 

3.12 查看innodb表的命中率

    这里innodb buffer 所指的是innodb_buffer_pool，也就是用来缓存innodb类型表和索引的内在空间。类似key buffer，同样可以根据mysql提供的相应的状态信息计算其命中率：

    innodb_buffer_read_hits=(1-innodb_buffer_pool_reads/innodb_buffer_pool_read_requests) * 100%;

--查看innodb表的命中率
show status like 'innodb_buffer_pool_read%';

Innodb_buffer_pool_read_ahead_rnd    0

Innodb_buffer_pool_read_ahead    0
Innodb_buffer_pool_read_ahead_evicted    0
Innodb_buffer_pool_read_requests    5785
Innodb_buffer_pool_reads    579
 

3.13 查看binlog的状态

show global status like 'bin%';

Binlog_cache_disk_use    0
Binlog_cache_use    0
Binlog_stmt_cache_disk_use    0
Binlog_stmt_cache_use    0

max_Binlog_size   # 代表二进制日志使用的最大值

max_binlog_cache_size    #代表二进制日志使用缓存的最大值

Binlog_cache_disk_use表示因为我们binlog_cache_size设计的内存不足导致缓存二进制日志用到了临时文件的次数

Binlog_cache_use  表示 用binlog_cache_size缓存的次数

当对应的Binlog_cache_disk_use 值比较大的时候 我们可以考虑适当的调高 binlog_cache_size 对应的值

       这里只是重点介绍了服务器的配置参数设置（线程和全局）和对应的状态参数的区别。而其实每一个标题都可以写一篇文章。尤其是定位表锁和查看日志文件这两个重点。这里一笔带过以后再专门讲解。匆匆写就，请高手斧正！我的邮箱rwangnqian@126.com