MySQL实战45讲Day28----如何判断数据库是否出问题

一、Select 1 判断：

 1、Select 1成功返回，只能说明这个库的进程还在，并不能说明主库没问题。

set global innodb_thread_concurrency=3;

CREATE TABLE `t` (
  `id` int(11) NOT NULL,
  `c` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

 insert into t values(1,1)

  设置innodb_thread_concurrency参数的目的是，控制InnoDB的并发线程上限。也就是说，一旦并发线程数达到这个值，InnoDB在接收到新请求的时候，就会进入等待状态，直到有线程退出。innodb_thread_concurrency设置成3，表示InnoDB只允许3个线程并行执行。
  把innodb_thread_concurrency设置成3，表示InnoDB只允许3个线程并行执行。而在上面的例子中，前三个session 中的sleep(100)，使得这三个语句都处于“执行”状态，以此来模拟大查询。session D里面，select 1是能执行成功的，但是查询表t的语句会被堵住。也就是说，如果这时候用select 1来检测实例是否正常的话，是检测不出问题的。
  在InnoDB中，innodb_thread_concurrency这个参数的默认值是0，表示不限制并发线程数量。但是，不限制并发线程数肯定是不行的。因为，一个机器的CPU核数有限，线程全冲进来，上下文切换的成本就会太高。所以，通常情况下，建议把innodb_thread_concurrency设置为64~128之间的值。

 2、并发连接和并发查询：

 <1>、并发连接：

  在show processlist的结果里，看到的几千个连接，指的就是并发连接。

 <2>、并发查询：

  当前正在执行”的语句，指的是并发查询。

 <3>、设置innodb_thread_concurrency参数的原因：

  并发连接数达到几千个影响并不大，就是多占一些内存而已。而并发查询太高才是CPU杀手。

 <4>、在线程进入锁等待以后，并发线程的计数会减一的原因：

  就是说等行锁（也包括间隙锁）的线程是不算在innodb_thread_concurrency参数值里面的。MySQL这样设计是非常有意义的。因为，进入锁等待的线程已经不吃CPU了；更重要的是，必须这么设计，才能避免整个系统锁死。

二、查表判断：

 1、判断方法：

  在系统库（mysql库）里创建一个表，比如命名为health_check，里面只放一行数据，然后定期执行：
mysql> select * from mysql.health_check;
使用这个方法，可以检测出由于并发线程过多导致的数据库不可用的情况。

 2、空间满了以后，这种方法变得不好使的原因：

  更新事务要写binlog，而一旦binlog所在磁盘的空间占用率达到100%，那么所有的更新语句和事务提交的commit语句就都会被堵住。但是，系统这时候还是可以正常读数据的。

三、更新判断：

 1、判断方法：

 <1>、方法一：

  放一个timestamp字段，用来表示最后一次执行检测的时间。这条更新语句类似于：
mysql> update mysql.health_check set t_modified=now();
节点可用性的检测都应该包含主库和备库。如果用更新来检测主库的话，那么备库也要进行更新检测。但是，备库的检测也是要写binlog的。由于一般会把数据库A和B的主备关系设计为双M结构，所以在备库B上执行的检测命令，也要发回给主库A。此时，如果主库A和备库B都用相同的更新命令，就可能出现行冲突，也就是可能会导致主备同步停止。

 <2>、方法二：

  mysql.health_check表上存入多行数据，并用A、B的server_id做主键。

mysql> CREATE TABLE `health_check` (
  `id` int(11) NOT NULL,
  `t_modified` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB;

/* 检测命令 */
insert into mysql.health_check(id, t_modified) values (@@server_id, now()) on duplicate key update t_modified=now();

 2、出现“判定慢”问题的原因：

  所有的检测逻辑都需要一个超时时间N。比如说执行一条update语句，超过N秒后还不返回，就认为系统不可用。
  但是当一个日志盘的IO利用率已经是100%的时候，整个系统响应非常慢，已经需要做主备切换了。但是IO利用率100%表示系统的IO是在工作的，每个请求都有机会获得IO资源，执行自己的任务。而检测使用的update命令，需要的资源很少，所以可能在拿到IO资源的时候就可以提交成功，并且在超时时间N秒未到达之前就返回给了检测系统。检测系统一看，update命令没有超时，于是就得到了“系统正常”的结论。也就是说，这时候在业务系统上正常的SQL语句已经执行得很慢了，但是DBA上去一看，HA系统还在正常工作，并且认为主库现在处于可用状态。

三、外部检测：

 1、外部检测包含：

  Select 1 判断、查表判断、更新判断。

 2、外部检测存在的问题：

  外部检测都需要定时轮询，所以系统可能已经出问题了，但是却需要等到下一个检测发起执行语句的时候，才有可能发现问题。而且，会可能第一次轮询还不能发现，这就会导致切换慢的问题。

四、内部统计：

 1、可以通过获取内部每一次IO请求的时间来判断数据库是否出问题：

  MySQL 5.6版本以后提供了performance_schema库，在file_summary_by_event_name表里统计了每次IO请求的时间。file_summary_by_event_name表里有很多行数据，先看event_name='wait/io/file/innodb/innodb_log_file’这一行。

performance_schema.file_summary_by_event_name的一行

这一行表示统计的是redo log的写入时间：

• 第一列EVENT_NAME 表示统计的类型。

  接下来的三组数据，显示的是redo log操作的时间统计：

• 第一组五列，是所有IO类型的统计。其中，COUNT_STAR是所有IO的总次数，接下来四列是具体的统计项， 单位是皮秒；前缀SUM、MIN、AVG、MAX，顾名思义指的就是总和、最小值、平均值和最大值。

• 第二组六列，是读操作的统计。最后一列SUM_NUMBER_OF_BYTES_READ统计的是，总共从redo log里读了多少个字节。

• 第三组六列，统计的是写操作。

• 第四组数据，是对其他类型数据的统计。在redo log里，可以认为它们就是对fsync的统计。

 2、打开redo log的时间监控的方法：

mysql> update setup_instruments set ENABLED='YES', Timed='YES' where name like '%wait/io/file/innodb/innodb_log_file%';