MySQL深入——20

如何判断一个数据库是不是出问题了

1.select 1

若select 1成功则表明主库进程没问题。但是仔细想想，这ok吗？

我们来看看下面这个例子，

Seeion A select sleep（100）from t；

Session B select * from t；

t是加锁的会被堵住。

在InnoDB当中，有innodb_thread_concurrency参数，其目的是控制InnoDB的并发线程上限，当达到上限的时候，会进入sleep状态，直到有线程退出，它的默认值为0，表示不限制并发线程的数量，通常情况下设置为64-128之间。

并发连接和并发查询并不是一个概念，在show processlist中看到几千个连接，指并发连接，正在执行的语句为并发查询。

并发连接到几千并不是很高，多占了一些内存，并发查询才是CPU杀手，需要设置innodb_thread_concurrency参数。

在线程进入锁等待时，并发线程会减一，也就是说等行锁并不包括在其中。MySQL这样设置使得等待锁的线程不吃CPU资源。若不这样设置，碰到了行的热点更新，系统就会被锁死。

2.查表判断 Health_check

为了检测InnoDB并发线程过多导致不可用情况，在系统库当中创建一个新表，定期对该表进行查询操作，若是可用的，则系统库可用。

空间满了之后，更新事务需要写binlog，一旦binlog在磁盘当中占用率达到百分之一百，所有的更新和commit都会被锁住，但是依然可以查询，这就出现了漏洞，所以我们要更新策略，语句不进行查询，进行更新。

3.更新查询

常见的为放一个timetamp字段，用于表示最后一次检测时间。

主库备库都要检测，因为备库检测也要写binlog，故设置为双M结构

但凡是两个库都采用相同的更新命令。

Health_check就会出现行冲突。

所以health_check不能只有一个行数据，可以使用两个库的sever_id作为数据创建。

由于两个库的sever_id被规定不能相同，所以不会发生冲突。

存在判断慢的问题，涉及到了IO资源的分配，日志资源利用为百分之百的时候，系统响应慢，已经要做主备切换了。

Update命令需要的IO资源少，所以拿到的IO资源之后就可能完成了，返回后发现没有超时，就会认为是正常的。

并且外部查询是定时的，有可能已经出现问题了但是很久才发现，所以会出现检测慢的问题。

4.内部查询

通过了上面的分析，通过对内部IO时间进行判断就十分可靠了。

5.6之后的performance_schema库，在file_summany_by_event_name当中有每次的IO请求时间。可以通过Max_TIMER来判断出是否出现了问题，不如可以设置阈值，若是超过了200毫秒就报为异常。

select event_name MAX_TIMER_WAIT FROM performance_schema发现异常之后进行主备切换即可。