MySQL45讲 第二十九讲 怎样判断一个数据库是不是出问题了？——阅读总结
在 MySQL 数据库的运维管理中，及时正确地判断数据库实例是否出现问题至关重要。这不仅关系到数据的可用性和完整性，还直接影响到业务体系的正常运行。讨怎样判断一个 MySQL 数据库实例是否出问题，详细介绍多种检测方法及其优缺点。
一、检测数据库实例健康状态的重要性
在一主一备的双 M 架构或一主多从架构中，主备切换是保障数据库高可用性的关键操纵。而主备切换通常由 HA 体系发起，此中被动切换往往是由于主库出现问题。因此，正确判断主库是否出问题是实现高效主备切换、确保业务连续性的前提。
二、常见检测方法及问题分析
（一）select 1 判断法
- 原理与范围性：很多人认为通过实行 select 1 语句，若能成功返回则表示数据库实例正常。然而，实际环境并非如此。例如，设置 innodb_thread_concurrency 参数为 3（控制 InnoDB 并发线程上限），并开启三个包含 select sleep (100) from t 语句的会话（模拟大查询），**此时再实行 select 1 可以成功，但查询表 t 的语句会被壅闭。**这表明 select 1 成功返回仅能说明数据库历程存在，无法全面反映数据库实例的健康状况，如无法检测出 InnoDB 并发线程数过多导致的体系不可用环境。
- 并发连接与并发查询概念辨析：这里需要明确并发连接和并发查询的区别。show processlist 效果中的几千个连接指的是并发连接，而 “当前正在实行” 的语句才是并发查询。并发连接数到达几千个对体系影响主要是多占内存，而并发查询过高才是 CPU 杀手，这也是设置 innodb_thread_concurrency 参数的重要缘故起因。
（二）查表判断法
- 改进思路：为检测 InnoDB 并发线程数过多导致的问题，可在体系库（mysql 库）创建一个只含一行数据的表（如 health_check），定期实行 select * from mysql.health_check 语句。如许，当并发线程过多导致数据库不可用时，该查询语句也会受到影响，从而检测出问题。
- 空间满问题的挑衅：然而，当 binlog 所在磁盘空间占用率到达 100% 时，全部更新语句和事务提交的 commit 语句会被壅闭，但体系仍可正常读数据。此时，上述查询语句无法检测出这种因空间满导致的数据库问题，需要进一步改进检测方法。
（三）更新判断法
- 详细操纵与上风：将检测语句改为更新语句，如 update mysql.health_check set t_modified = now ()，并在表中增加一个 timestamp 字段用于记录最后一次实行检测的时间。同时，为制止主备库检测命令行冲突（主备库都实行雷同更新命令可能导致主备同步制止），可在 mysql.health_check 表中存入多行数据，以主、备库的 server_id 做主键，由于 MySQL 规定主库和备库的 server_id 必须差别。如许，主备库各自的检测命令就不会发生冲突，该方法能够在一定程度上更有效地检测数据库实例的健康状态。
- 判断慢问题剖析：**尽管更新判断法相对常用，但存在 “判断慢” 的问题。**例如，在日志盘 IO 利用率为 100% 的环境下，虽然体系响应极慢已需主备切换，但由于 IO 利用率 100% 表示体系 IO 仍在工作，检测使用的 update 命令可能在拿到 IO 资源时提交成功并在超时时间内返回，导致检测体系误判数据库正常。这是由于外部检测基于定时轮询，具有随机性，体系可能在两次轮询间隔内出现问题，而运气不好时可能多次轮询都无法发现，从而导致切换慢。
三、基于内部统计的高级检测方法
（一）performance_schema 库的作用
针对外部检测方法的范围性，MySQL 5.6 版本以后提供的 performance_schema 库提供了更可靠的检测途径。该库中的 file_summary_by_event_name 表统计了每次 IO 请求的时间，
例如 event_name = 'wait/io/file/innodb/innodb_log_file' 这一行统计了 redo log 的写入时间，包罗全部 IO 类型的统计（COUNT_STAR 表示总次数，SUM、MIN、AVG、MAX_TIMER_WAIT 分别表示总和、最小值、平均值和最大值，单位为皮秒）、读操纵统计（SUM_NUMBER_OF_BYTES_READ 统计总共从 redo log 里读的字节数）、写操纵统计以及对其他类型数据（如 fsync）的统计。binlog 对应的是 event_name = "wait/io/file/sql/binlog" 这一行，其统计逻辑与 redo log 雷同。
（二）检测逻辑与阈值设定
通**过查看 MAX_TIMER_WAIT 的值，我们可以判断数据库是否存在问题。**例如，设定单次 IO 请求时间凌驾 200 毫秒为异常，使用类似 select event_name,MAX_TIMER_WAIT FROM performance_schema.file_summary_by_event_name where event_name in ('wait/io/file/innodb/innodb_log_file', 'wait/io/file/sql/binlog') 的语句作为检测逻辑。发现异常后，可使用 truncate table performance_schema.file_summary_by_event_name 语句清空之前的统计信息，以便后续监控再次出现异常时能正确累积监控值。不外，开启 performance_schema 的统计功能会有一定性能消耗，测试效果显示性能大概会下降 10% 左右，因此建议仅开启所需的统计项，如通过 update setup_instruments set ENABLED = 'YES', Timed = 'YES' where name like '% wait/io/file/innodb/innodb_log_file%' 语句开启 redo log 的时间监控。
四、总结与思索
我们介绍了多种检测 MySQL 实例健康状态的方法：
- select 1 判断法：虽然简单但不正确；
- 查表判断法：无法检测磁盘空间满的环境；
- 更新判断法：一定程度上检测主备库问题，但存在判断慢的问题；
- 基于 performance_schema 库的内部统计检测法：虽能在而内部统计检测法虽然更精确，但会带来性能消耗。
每个方法都有其改进的逻辑，但也都存在一定问题。例如，在实际应用中，需要根据业务需求和实际环境权衡选择符合的检测方法。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
