MYSQL之日志管理与配置参数的优化

最优配置模板

[client]
user=oceanstar
password=88888888

[mysql]
prompt=(\u@\h) [\d]>\_

# 服务器端
[mysqld]
# 设置3306端口
port=3306
user=mysql
character_set_server=utf8mb4
datadir=/home/ocean/workspace/mysql/mysql-data   # 设置mysql数据库的数据的存放目录
# bind_address = 10.166.224.32

########log settings########
expire_logs_days = 30   #设置所有日志的过期参数为30天，MYSQL会自动删除过期的日志。为0表示永远不删除。
log_error = error.log
slow_query_log = 1                 #开启慢查询日志
slow_query_log_file = slow.log     #指定日志文件存放文件
long_query_time = 2                #慢查询日志超时时间
log_timestamps = SYSTEM            # 指定时区为当前系统时区
#log_queries_not_using_indexes = 1  #未使用索引的查询记录到慢查询日志中
#log_throttle_queries_not_using_indexes = 10  #每分钟最多记录10条没有使用索引的SQL
log_slow_admin_statements = 1      -- 记录那些慢的optimize table，analyze table和alter table语句
log_slow_slave_statements = 1    -- --记录由Slave所产生的慢查询
min_examined_row_limit = 1000       --记录那些由于查找了多余1000次而引发的慢查询

每次更新my.cnf时记得必须重启才能生效

$ /etc/init.d/mysql.server restart 
[ ok ] Restarting mysql.server (via systemctl): mysql.server.service.

错误日志

由参数"log_error "指定存储位置。

 $ sudo tail -n 10 error.log  -- 查看错误日志

cat /dev/null > error.log;  //清空错误日志

慢查询日志

• 建议开启

1、参数

• slow_query_log
  on表示开启慢查询日志，用long_query_time变量的值来确定“慢查询”。
• slow_query_log_file
  指定慢查询日志存放位置
• long_query_time
  超过设定事件就将此记录到慢查询日志中
• log_timestamps
  控制 error log、slow_log、genera log，等等记录日志的显示时间参数，默认有两个值：UTC 和 SYSTEM。默认UTC，建议配置乘SYSTEM，否则会使得日志中记录的时间比中国这边的慢了 8 个小时
• log_throttle_queries_not_using_indexes
  用来表示每分钟允许记录到slow log的且未使用索引的SQL语句次数。该值默认为0，表示没有限制。在生产环境下，若没有使用索引，此类SQL语句会频繁地被记录到slow log，从而导致slow log文件的大小不断增加
• expire_logs_days
  用来控制binlog日志文件保留时间，超过保留时间的binlog日志会被自动删除
• slow_launch_time
  如果创建线程的时间超过该秒数，服务器增加Slow_launch_threads状态变量。

2、解读慢查询日志

如果想要测试

(root@localhost) [(none)]> select sleep(2);
+----------+
| sleep(2) |
+----------+
|        0 |
+----------+
1 row in set (2.00 sec)

下面是记录的没有生成索引的

# Time: 2019-02-27T02:14:42.318181-08:00
# User@Host: root[root] @ localhost [127.0.0.1]  Id:    14
# Query_time: 0.001154  Lock_time: 0.000069 Rows_sent: 1498  Rows_examined: 1498
use arguse;
SET timestamp=1551262482;
select * from caseall;

第1行，记录慢日志的时间
第2行，很明显不多解释
第3行，是整个语句的query time, Lock time, 返回或者发送了多少行， 执行的行数
第4行，是语句真正发生的时间
第5行，具体语句

通用日志

• 作用：会记录数据库所有的操作
• 基本上是不会开启的，开启性能下降明显
• 可以将日志保存到表mysql.general_log

> show variables like 'gene%';
+------------------+---------------------------------------------------+
| Variable_name    | Value                                             |
+------------------+---------------------------------------------------+
| general_log      | OFF                                               |
| general_log_file | /home/ocean/workspace/mysql/mysql-data/ubuntu.log |
+------------------+---------------------------------------------------+

二进制日志

• 作用：用于记录所有更改数据的语句。主要用于复制和即时点回复。默认开启
• 查看二进制日志的工具：mysqlbinlog

1、简介

• 二进制日志包含了所有更新了数据或者已经潜在更新了的数据(比如，没有匹配任何行的一个delete)的所有语句。语句以"事件"的形式保存，它描述数据更改。二进制日志还包含关于每个更新数据库的语句的执行时间信息。它不包含没有修改任何数据的语句。
• 二进制日志的主要目的是在数据库存在故障时，恢复时能够最大可能的更新数据库(即时点回复)，因为二进制日志包含备份后进行的所有更新。二进制日志还用于在主复制服务器上记录所有将发送给从服务器的语句。
• 那么二进制日志是记录执行的语句还是执行后的结果数据？

二进制表的记录时间

• 对于非事务表的更新执行完毕之后立即保存到二进制日志中。
• 对于事务表比如Innodb表，所有更改表的更新(INSERT，UPDATE，DELETE)被缓存起来，直到服务器接收到commot语句。在该点，执行完COMMIT之前，mysqld将整个事务写入二进制日志。当处理事务的线程启动时，它为缓冲查询分配binlog_cache_size【使用默认值即可，不要调整这个的值】大小的内存。如果语句大于该值，线程则打开临时文件来保存事务。线程结束之后临时文件被删除。

2、参数

• log_bin
  默认“ON”，开启二进制日志，
• log_bin_basename && log_bin_index
  | log_bin_basename | /home/ocean/workspace/mysql/mysql-data/binlog |
  | log_bin_index | /home/ocean/workspace/mysql/mysql-data/binlog.index |
  文件存储路径是：/home/ocean/workspace/mysql/mysql-data，文件名为binlog.000001，binlog.000002等等。
• sync_binlog
  如果对业务安全性要求极高，请设置为1.
  如果开启了主从，设置为1
  默认情况下，并不是每次写入时都将二进制日志与硬盘同步。因此如果操作系统或者机器崩溃，有可能二进制日志中最后的语句丢失了。要向防止这种情况，可以设置sync_binlog（1是最安全的值，但也是最慢的），使二进制日志在每N次二进制日志写入之后与硬盘同步。
  简单的说，1就是实时写。
  备注：可以分布设置sync_binlog为0或者1，然后对建表，更新数据，然后使用show master status; 命令查询当前正在更新的日志的大小：发现当sync_binlog为1时日志实时改变大小，如果为0则需要commit提交了才能改变大小【实际上日志信息已经被记录到了缓存里面去了，直到commit才写入磁盘】。
• max_binlog_size
  此参数限制二进制日志的最大尺寸，超过这个尺寸之后进行滚动，滚动时会创建一个新的编号大1的日志用于记录最新的日志，而原日志名字不会被改变。
  每次重启MYSQL服务，日志都会自动滚动一次。
  另外如果需要手动滚动，则使用命令：

mysql>flush logs;

• binlog_cache_size：
  是global参数，默认32768，即32K，可选范围在[4096，4294967295]
  作用：为每隔session分配内存，在事务过程中用来存储二进制日志的缓存，可以提高记录binlog的效率。
  如何设置：一般不需要更改，具体可以参见 https://blog.csdn.net/lxpbs8851/article/details/38455223

3、解读

命令

(root@localhost) [(none)]> show binary logs;  --有哪些的二进制日志
+---------------+-----------+-----------+
| Log_name      | File_size | Encrypted |
+---------------+-----------+-----------+
| binlog.000001 |     39647 | No        |
| binlog.000002 |    647566 | No        |
| binlog.000003 |      1435 | No        |
| binlog.000004 |       178 | No        |
| binlog.000005 | 194807619 | No        |
| binlog.000006 |       155 | No        |
+---------------+-----------+-----------+


(root@localhost) [(none)]> show master status;  -- 当前正在记录使用的二进制
+---------------+----------+--------------+------------------+-------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+---------------+----------+--------------+------------------+-------------------+
| binlog.000006 |      155 |              |                  |                   |
+---------------+----------+--------------+------------------+-------------------+

(root@localhost) [tpcc]> show binlog events in 'binlog.000006';  -- 查看这个二进制日志的内容
+---------------+-----+----------------+-----------+-------------+-------------------------------------------------------------------------+
| Log_name      | Pos | Event_type     | Server_id | End_log_pos | Info                                                                    |
+---------------+-----+----------------+-----------+-------------+-------------------------------------------------------------------------+
| binlog.000006 |   4 | Format_desc    |         1 |         124 | Server ver: 8.0.15, Binlog ver: 4                                       |
| binlog.000006 | 124 | Previous_gtids |         1 |         155 |                                                                         |
| binlog.000006 | 155 | Anonymous_Gtid |         1 |         232 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'                                    |
| binlog.000006 | 232 | Query          |         1 |         342 | use `tpcc`; create table t1(a int) /* xid=1364003 */                    |
| binlog.000006 | 342 | Anonymous_Gtid |         1 |         421 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS'   

(root@localhost) [tpcc]> show binlog events in 'binlog.000006' from 769;  -- 重哪一个位置开始看 ，769为时间位置Pos

二进制日志不能直接删除的，如果使用rm删除，可能会导致数据库的崩溃。必须使用purge删除日志。但是尽量不要去删除二进制日志。

PURGE { BINARY | MASTER } LOGS
{ TO 'log_name' | BEFORE datetime_expr }

用于删除列于在指定的日志或日期之前的日志索引中的所有二进制日志。这些日志也会从记录在日志索引文件中的清单中被删除，这样被给定的日志成为第一个。

例子：

(root@localhost) [tpcc]> PURGE BINARY LOGS TO 'binlog.000004';  -- 删除000004之前的日志
 
(root@localhost) [tpcc]>PURGE BINARY LOGS BEFORE '2018-04-28 23:59:59';  -- 删除2018-04-28 23:59:59之前的日志

mysqlbinlog

binlog.00000x等不是文本文件，不能通过cat命令查看，可以使用mysqlbinlog
mysqlbinlog 是MYSQL自带的一个以用户可视的方式展示出二进制日志中的内容的命令行工具。

在进行恢复的过程中，依然会产生binlog日志，因此，我们需要临时关闭binlog日志

(root@localhost) [tpcc]> set sql_log_bin=0;  #临时关闭binlog日志

sql_log_bin是会话级别的，退出数据库之后就恢复为ON了

~/workspace/mysql/mysql-data$ mysqlbinlog binlog.000001   ## 。可能出现问题1
~/workspace/mysql/mysql-data$ mysqlbinlog binlog.000001 --start-position 39270 --stop-position 39647   ## 查看39270到39647之间发生的事件
~/workspace/mysql/mysql-data$ mysqlbinlog binlog.000001 --start-position 39270 --stop-position 39647 > 1.sql   # 可以将这个事件导出为sql语句。可能出现问题2
(root@localhost) [tpcc]> source 1.sql    -- 数据库中执行sql语句

(root@localhost) [tpcc]> set sql_log_bin=1;       # 开启

备注：
1、如果出现问题:mysqlbinlog: File ‘binlog.000003’ not found (OS errno 13 - Permission denied)
原因：权限问题
解决：

~/workspace/mysql/mysql-data$ sudo chmod +777 binlog.000001

2、出现错误：bash: 1.sql: Permission denied
原因：权限问题
解决：

~/workspace/mysql/mysql-data$ sudo chmod +777 1.sql

配置参数

当MYSQL实例启动时，数据库会先去读一个配置参数文件，用来讯在数据库的各种文件所在位置以及指定某些初始化参数。默认情况下，MYSQL实例会按照一定的顺序在指定的位置进行读取。

1、配置文件在哪里

$ /usr/local/mysql/bin/mysqld --verbose --help| grep -A 1 "Default options"  --查看MYSQL的配置文件
$/usr/local/mysql/bin/mysqld  --help -vv | grep my.cnf --查看MYSQL的配置文件
$ mysql --help --verbose | grep my.cnf  --查看MYSQL的配置文件                 
  order of preference, my.cnf, $MYSQL_TCP_PORT,
 /etc/my.cnf /etc/mysql/my.cnf/usr/local/mysql/etc/my.cnf ~/.my.cnf 
$ mysql --help --verbose | less  查看MYSQL参数默认值MYSQL配置参数

MYSQL默认根据 /etc/my.cnf ，/etc/mysql/my.cnf，/usr/local/mysql/etc/my.cnf ，~/.my.cnf 这四个文件的顺序读取配置值，如果重复的参数，后面的就覆盖前面的。

注意：原生的/etc/或者/etc/mysql/等目录下时没有my.cnf文件的，需要我们手动在/ect/等目录下创建一个my.cnf文件，然后写入配置项

还可以通过defaults-file指定默认配置文件

$ mysqld --help -vv | grep defaults-file
--defaults-file=#       Only read default options from the given file #.

2、如果查看配置参数

mysql> show variables; # 显示当前mysql的所有参数，且无隐藏参数
mysql> show variables like "max_%"; #查以max_开头的变量

不建议将慢查询日志写入表mysql.slow_log，两个原因：性能变慢，如果备份可能会将慢查询日志也一起备份了

3、配置参数的分类

1、从作用域上可以分为global和session

• 设置全局(GLOBAL)参数

mysql> set global slow_query_log = off; #不加global，会提示错误
                                        #slow_query_log是全局参数

mysql> set slow_query_log = off;  # 下面就报错了，默认是会话参数
ERROR 1229 (HY000): Variable 'slow_query_log' is a GLOBAL variable and should be set with SET GLOBAL

mysql> set global long_query_time = 1.5;  -- 针对全局的参数，对已经创建的链接没有用，对当前会话页没有用，只会对新创建的链接有用

• •设置会话(SESSION)参数

mysql> set session long_query_time = 1.5;  -- 设置会话级别的参数，针对当前链接的会话有效,session可以省略
mysql> show variables like 'long%time';
mysql> show global variables like 'long%time';

有些参数，即存在于GLOBAL又存在于SESSION, 比如autocommit (PS：MySQL默认是提交的)

•设置会话(SESSION)参数
mysql> set autocommit = 0;  # 当前会话生效
mysql> set session autocommit = 0;  # 当前会话生效
autocommit 只能在会话中进行修改

autocommit同样在GLOBAL中, 也有同样的参数
mysql> set global autocommit = 1; #当前实例，全局生效


注意：如果这个时候/etc/init.d/mysqld restart, 则全局的autocommit的值会变成默认值，或者依赖于my.cnf的设置值。

执行的效果如下：
mysql> show variables like "slow%"; # 原值为ON
+---------------------+----------+
| Variable_name       | Value    |
+---------------------+----------+
| slow_launch_time    | 2        |
| slow_query_log      | OFF      |
| slow_query_log_file | slow.log |
+---------------------+----------+
3 rows in set (0.00 sec)

mysql> select @@session.autocommit; # 等价于 slect @@autocomit;
+----------------------+
| @@session.autocommit |
+----------------------+
|                    0 |
+----------------------+
1 row in set (0.00 sec)

mysql> select @@global.autocommit;       
+---------------------+
| @@global.autocommit |
+---------------------+
|                   1 |
+---------------------+
1 row in set (0.00 sec)

2、从类型上可以分为可修改[动态]和只读[静态]参数

• 用户可以在线修改非只读参数，只读参数只能通过配置文件修改并重启数据库生效

3、 所有参数的修改都不持久化

• : 所有的在线修改过的参数(GLOBAL/SESSION)，在重启后，都会丢失，不会写如my.cnf，无法将修改进行持久化

mysql> use performance_schema
mysql> show tables like '%variable%';
+-------------------------------------------+
| Tables_in_performance_schema (%variable%) |
+-------------------------------------------+
| global_variables                          |      
| persisted_variables                       |
| session_variables                         |
| user_variables_by_thread                  |
| variables_by_thread                       |
| variables_info                            |
+-------------------------------------------+
mysql> select * from variables_by_thread where variable_name = "long_query_time";  --查看每个会话的每个变量的值
+-----------+-----------------+----------------+
| THREAD_ID | VARIABLE_NAME   | VARIABLE_VALUE |
+-----------+-----------------+----------------+
|        53 | long_query_time | 1.500000       |  
+-----------+-----------------+----------------+
mysql> SELECT connection_id(); -- 查看当前会话的ID
+-----------------+
| connection_id() |
+-----------------+
|              14 |
+-----------------+
mysql> show processlist;  --查看当前的每个会话正在干什么
+----+-----------------+-----------+--------------------+---------+------+------------------------+------------------+
| Id | User            | Host      | db                 | Command | Time | State                  | Info             |
+----+-----------------+-----------+--------------------+---------+------+------------------------+------------------+
|  4 | event_scheduler | localhost | NULL               | Daemon  | 4774 | Waiting on empty queue | NULL             |
| 14 | root            | localhost | performance_schema | Query   |    0 | starting               | show processlist |
+----+-----------------+-----------+--------------------+---------+------+------------------------+------------------+
> select * from threads where thread_id = 53 \G
*************************** 1. row ***************************
          THREAD_ID: 53
               NAME: thread/sql/one_connection
               TYPE: FOREGROUND
     PROCESSLIST_ID: 14
   PROCESSLIST_USER: root
   PROCESSLIST_HOST: localhost
     PROCESSLIST_DB: performance_schema
PROCESSLIST_COMMAND: Query
   PROCESSLIST_TIME: 0
  PROCESSLIST_STATE: statistics
   PROCESSLIST_INFO: select * from threads where thread_id = 53
   PARENT_THREAD_ID: NULL
               ROLE: NULL
       INSTRUMENTED: YES
            HISTORY: YES
    CONNECTION_TYPE: Socket
       THREAD_OS_ID: 2952
     RESOURCE_GROUP: USR_default

并发连接参数：max_connections

max_connections：允许连接到mysql最大连接数，默认151。

MySQL 提供了 Threads_connected 指标以记录连接的线程数——每个连接对应一个线程。通过监控该指标与先前设置的连接限制，你可以确保服务器拥有足够的容量处理新的连接。MySQL 还提供了 Threads_running 指标，帮助你分隔在任意时间正在积极处理查询的线程与那些虽然可用但是闲置的连接。

• Threads_connected：当所有可用连接都被占用时，如果一个客户端试图连接至 MySQL，后者会返回 “Too many connections(连接数过多)”错误，同时将 Connection_errors_max_connections 的值增加。为了防止出现此类情况，你应该监控可用连接的数量，并确保其值保持在 max_connections 限制以内。

mysql> show status like '%Threads_connected%';
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 1     |
+-------------------+-------+

mysql> show status like '%Threads_running%';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| Threads_running | 1     |
+-----------------+-------+

如果服务器真的达到 max_connections 限制，它就会开始拒绝新的连接。在这种情况下，Connection_errors_max_connections 指标就会开始增加，同时，追踪所有失败连接尝试的 Aborted_connects 指标也会开始增加。

• Connection_errors_max_connections 当MySQL的最大并发数大于系统变量（show variables）中max_connections的最大并发数，因此而被拒绝的次数，将会记录在这个变量里。如果Connection_error_max_connections值比较大，则说明当前系统并发比较高，要考虑调大max_connections的值。
• Aborted_connects：如果该计数器在不断增长，意味着用户尝试连接到数据库的努力全都失败了。此时，应该借助 Connection_errors_max_connections 与 Connection_errors_internal 之类细粒度高的指标调查该问题的根源。
• Connection_errors_internal：只会在错误源自服务器本身时增加。内部错误可能反映了内存不足状况，或者服务器无法开启新的线程。

mysql> show status like '%Connection_errors_max_connections%';
+-----------------------------------+-------+
| Variable_name                     | Value |
+-----------------------------------+-------+
| Connection_errors_max_connections | 0     |
+-----------------------------------+-------+
1 row in set (0.00 sec)

mysql> show status like '%Aborted_connects%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Aborted_connects | 24    |
+------------------+-------+

mysql> show status like '%Connection_errors_internal%';
+----------------------------+-------+
| Variable_name              | Value |
+----------------------------+-------+
| Connection_errors_internal | 0     |
+----------------------------+-------+

怎么调整

监控客户端连接情况相当重要，因为一旦可用连接耗尽，新的客户端连接就会遭到拒绝。

(1) 什么时候应该调整值
如果状态变量connection_errors_max_connections不为零，并且一直在增长，就说明不断有连接请求因数据库连接数量已经到达最大的值而失败，应该考虑max_connections的值。

> show status like 'connection_errors_max_connections';
+-----------------------------------+-------+
| Variable_name                     | Value |
+-----------------------------------+-------+
| Connection_errors_max_connections | 0     |
+-----------------------------------+-------+

MySQL配置文件中max_connections值过小可能会造成”MySQL: ERROR 1040: Too many connections”，这时应该调整max_connections的大小【另一种原因是访问量过高，MySQL服务器抗不住，这个时候就要考虑增加从服务器分散读压力】

> show variables like 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 151   |
+-----------------+-------+
> show status like 'max_used_connections';  --服务器响应的最大连接数:（并发）
+----------------------+-------+
| Variable_name        | Value |
+----------------------+-------+
| Max_used_connections | 8     | --最大并发连接数8
+----------------------+-------+

max_used_connections / max_connections * 100% （理想值≈ 85%）
如果max_used_connections跟max_connections相同 那么就是max_connections设置过低或者超过服务器负载上限了，低于10%则设置过大。

• 增加max_connections参数的值，不会占用太多系统资源。系统资源（CPU、内存）的占用主要取决于查询的密度、效率等；

(2) 注意
每一个session操作MySQL数据库表都需要占用文件描述符，数据库连接本身也要占用文件描述，因此在增大max_connections时，也要考虑open_files_limit的设置是否够用

>  show variables like 'open%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| open_files_limit | 8161  |
+------------------+-------+

open_files_limit 是mysql中的一个全局变量且不可动态修改。它控制着mysqld进程能使用的最大文件描述(FD)符数量。需要注意的是这个变量的值并不一定是你设定的值，mysqld会在系统允许的情况下尽量获取更多的FD数量。

• MySQL无论如何都会保留一个用于管理员（SUPER）登陆的连接，用于管理员连接数据库进行维护操作，即使当前连接数已经达到max_connections。因此MySQL的实际最大可连接数为max_connections+1；

> show status like 'Connections';  --MySQL服务器的连接尝试次数（成功与否）。
> show processlist;  ##显示当前正在执行的mysql连接

并发线程池参数：thread_cache_size

> show variables like 'thread%';
+-------------------+---------------------------+
| Variable_name     | Value                     |
+-------------------+---------------------------+
| thread_cache_size | 9                         |  服务器的池中最多可以存放32个连接线程
| thread_handling   | one-thread-per-connection |
| thread_stack      | 286720                    | 为每个线程分配280K内存空间
+-------------------+---------------------------+

• thread_cache_size 设置连接线程缓存的数目。这个缓存相当于MySQL线程的缓存池（thread cache pool）,将空闲的连接线程放入连接池中缓存起来，而非立即销毁。当有新的连接请求时，如果连接池中有空闲的连接，则直接使用。否则要重新创建线程。创建线程是一个不小的系统开销。这个参数和物理内存由关系：
  1G —> 8
  2G —> 16
  3G —> 32
  3G —> 64
• thread_stack stack 是堆的意思，知道进程和线程都是有唯一的ID的，进程的ID系统会维护，二线程的ID,则由具体的线程库区维护，当进程或者线程休眠的时候，进程的上下文信息要在内存中开辟出一块区域，保存进程的上下文信息，以便于迅速唤醒程序。默认为MySQL的每个线程设置的堆栈大小为：286720 /1024=280K，一般不用动
• thread_handling 默认值是： one-thread-per-connection 表示为每个连接提供或者创建一个线程来处理请求，直至请求完毕，连接销毁或者存入缓存池。当值是no-threads 时，表示在始终只提供一个线程来处理连接，一般是单机做测试使用的。

>  show status like 'Threads%';  --查看线程状态信息
+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_cached    | 2     |   mysql管理的线程池中还有多少可以被复用的资源
| Threads_connected | 6     |  已经打开的连接数，Threads_connected 跟show processlist结果相同
| Threads_created   | 8     |  表示创建过的线程数，如果发现Threads_created值过大的话，表明MySQL服务器一直在创建线程，这也是比较耗资源，可以适当增加配置文件中thread_cache_size值，查询服务器
| Threads_running   | 2     | 正在运行的连接数，这个数值一般远低于connected数值，准确的来说，Threads_running是代表当前并发数
+-------------------+-------+
> show variables like 'thread_cache_size';  --如果我们在MySQL服务器配置文件中设置了thread_cache_size，当客户端断开之后，服务器处理此客户的线程将会缓存起来以响应下一个客户而不是销毁(前提是缓存数未达上限)。

• thread_cache命中率公式为:这个结果越大越好，最好不要小于90%，如果小了最改动thread_cache_size

>Thread_connected = SHOW GLOBAL STATUS LIKE Thread_created;
> Connections = SHOW GLOBAL STATUS LIKE 'Connections';
Thread_Cache_Hit=(1 - (Threads_created / Connections)) * 100

突发参数之back_log

• MySQL在很短的时间内，突然收到很多的连接请求时，MySQL会将不能来得及处理的连接请求保存在堆栈中，以便MySQL后续处理。back_log参数设置了堆栈的大小.
• 如果需要在较短时间内处理大量请求，应该考虑适当增大back_log的值

> show variables like 'back_log';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| back_log      | 151   |
+---------------+-------+

> show status like 'Aborted%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Aborted_clients  | 9     |   --MySQL 客户机被异常关闭的次数。
| Aborted_connects | 2     |   --试图连接到MySQL服务器而失败的连接次数。
----------------------------

$  show status like 'Slow%'; 
Slow_lunch_threads 创建线程的时间过长，超过slow_launch_time的设定值，则会记录。

$ show status like 'Connection_error%';   --来查看连接的错误状态信息：
Connection_errors_peer_address 查找MySQL客户机IP地址是发生的错误数。

参考：https://blog.csdn.net/jiekou0376/article/details/80527046
https://blog.csdn.net/h106140873/article/details/78852185
https://blog.csdn.net/bzfys/article/details/48161021
http://www.gaodaima.com/19263.html
https://segmentfault.com/a/1190000005726466
https://blog.csdn.net/wangpeng198688/article/details/51682732