1.select 1判断
select 1 成功返回，只能说明这个库的进程还在，并不能说明主库没问题。innodb_thread_concurrency，该参数控制 InnoDB 的并发线程上限。也就是说，一旦并发线程数达到这个值，InnoDB 在接收到新请求的时候，就会进入等待状态，直到有线程退出。并发连接数达到几千个影响并不大，就是多占一些内存而已。应该关注的是并发查询，因为并发查询太高才是 CPU 杀手。通常情况下，建议把 innodb_thread_concurrency 设置为 64~128 之间的值。在线程进入锁等待以后，并发线程的计数会减一，不会计入并发线程数中。当同时在执行的语句超过了设置的 innodb_thread_concurrency 的值中，select 1还是返回成功的，但系统已经不行了。
2.查表判断
为了避免线程过多的问题，可以在系统库（mysql 库）里创建一个表，里面只放一行数据，然后定期执行查询，但无法检测空间的问题。
3.更新判断
常见做法是放一个 timestamp 字段，用来表示最后一次执行检测的时间，但外部检测都需要定时轮询，所以系统可能已经出问题了，但是却需要等到下一个检测发起执行语句的时候，我们才有可能发现问题。而且，如果你的运气不够好的话，可能第一次轮询还不能发现，这就会导致切换慢的问题。
4.内部统计
MySQL 5.6 版本以后提供的 performance_schema 库，在 file_summary_by_event_name 表里统计了每次 IO 请求的时间。这样你就可以通过 MAX_TIMER 的值来判断数据库是否出问题了。但如果打开所有的 performance_schema 项，性能大概会下降 10% 左右。可以只打开自己需要的项进行统计。比如要打开redo log的时间监控：
update setup_instruments set ENABLED='YES', Timed='YES' where name like '%wait/io/file/innodb/innodb_log_file%';
目前使用非常广泛的 MHA（Master High Availability），默认使用的还是select 1。推荐方案：优先考虑 update 系统表，然后再配合增加检测 performance_schema 的信息。
参考资料：丁奇，MySQL实战45讲
部分内容来自网络，如有侵权请联系作者删除。
