怎么判断主库出问题了？

一.select 1 判断

• select1成功返回，只能说明这个库的进程还在，并不能说明主库没问题

innodb_thread_concurrency参数

    控制InnoDB并发线程上线，一旦并发线程数达到这个值，新请求就会进入等待状态，直到线程退出

产生问题：

  我们用select 1检测实例是否正常，但是其他查询表的语句依然可能会被阻塞，因而判定是正常的

并发连接和并发查询

•   在 show processlist结果里，看到的几千个连接，指的是并发连接
•   当前正在执行的就是并发查询

二.查表判断

 解决方法：

     在系统库（mysql库里）创建一个表，比如heath_check,里面只放一行数据，然后定期执行

select * from mysql.health_check;

优点：

    检测出并发线程过多导致数据库不可用

缺点：

• 硬件空间满了，
• 更新事务要写binlog，一旦binlog所在磁盘空间占用率达到100%，那么所有更新语句和事务提交的commit语句都会被堵住，系统可以读但是不可以写

三.更新判断

    放一个timestamp字段，来表示最后一次执行检测的时间

update mysql.health_check set t_modified=now();

更新语句，如果失败或者超时，就可以发起主备切换了，为什么还会有判定慢的问题呢？

解决问题：

    服务器IO资源分配问题

•  一个日志盘的IO利用率已经是100%场景。这时候整个系统响应非常慢，需要做主备切换
• 每个请求都有机会获得IO资源，执行自己的任务，而我们检测使用的update命令，需要的资源很少，所以执行几率比较高

update命令没有超时，就得到"系统正常"结论

四.内部统计

• MySQL5.6版本以后提供了performance_shcema库，就在file_dummary_by_event_name表里统计了每次IO请求的时间