核心要点
- MySQL 监控不能只看数据库进程是否存活，还要看日志、慢查询、连接、锁等待、缓冲池、磁盘 I/O 和复制状态。
SHOW STATUS、SHOW PROCESSLIST、Performance Schema 和慢查询日志适合现场诊断；Prometheus、Zabbix、Nightingale + Categraf 适合持续采集和告警。- 指标必须和配置一起看，例如连接数异常时要同时检查
max_connections，慢查询增加时要结合 SQL、锁和资源使用分析。 - 监控目标不是“指标越多越好”，而是让 DBA、运维和研发能快速判断数据库是否可用、哪里变慢、是否需要扩容或调优。
MySQL 监控主要分三个层面：
- MySQL 进程本身的存活性
- MySQL 的运行日志、慢日志
- MySQL 暴露的性能指标
这三个层面对应不同问题。进程存活性回答“数据库是否还在运行”；日志和慢日志回答“发生了什么异常、哪些 SQL 变慢”；性能指标回答“连接、查询、缓存、锁、I/O、复制等状态是否健康”。实际排障时，这些信息通常需要组合使用。
使用 MySQL 内置工具
MySQL 提供了一些内置的工具和命令，可以帮助你监控数据库的状态。
SHOW STATUS
SHOW STATUS 命令可以查看 MySQL 服务器的性能指标，比如连接数、查询数、缓存命中率、InnoDB引擎的各类指标等。
SHOW GLOBAL STATUS;
通过分析这些状态变量，可以了解数据库的运行状况。另外，MySQL 还提供了 SHOW VARIABLES 命令，可以查看 MySQL 服务器的配置参数。有时会在配置参数和状态变量之间找到一些关联。比如连接数过多，可能是 max_connections 参数设置过小。
SHOW PROCESSLIST
SHOW PROCESSLIST 可以查看当前正在执行的查询和连接信息，帮助识别慢查询或阻塞问题。
SHOW PROCESSLIST;
比如某个 SQL 执行的很慢，通过 SHOW PROCESSLIST 就可以看到这个查询的状态。
Performance Schema
MySQL 的 Performance Schema 提供了详细的性能监控数据，比如我们经常使用如下的一些查询：
哪类SQL执行最多
SELECT * FROM performance_schema.events_statements_summary_by_digest ORDER BY COUNT_STAR DESC limit 10;
哪类SQL的平均响应时间最多
SELECT * FROM performance_schema.events_statements_summary_by_digest ORDER BY AVG_TIMER_WAIT DESC limit 10;
哪个表物理IO最多
SELECT
file_name,
event_name,
SUM_NUMBER_OF_BYTES_READ,
SUM_NUMBER_OF_BYTES_WRITE
FROM file_summary_by_instance
ORDER BY SUM_NUMBER_OF_BYTES_READ + SUM_NUMBER_OF_BYTES_WRITE DESC LIMIT 10\G
慢查询日志（Slow Query Log）
启用慢查询日志可以记录执行时间超过指定阈值的查询，帮助定位性能瓶颈。
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 2; -- 记录超过 2 秒的查询
使用监控工具
除了 MySQL 自带的工具，许多开源监控工具可以更直观地监控 MySQL 的性能和状态。
- Prometheus + MySQL Exporter：Prometheus 是一款开源的监控系统，MySQL Exporter 可以将 MySQL 的性能指标暴露给 Prometheus，通过 Grafana 展示监控数据。
- Zabbix：Zabbix 是一款功能强大的监控系统，支持 MySQL 的监控。不过老版本的 Zabbix 对 MySQL 的监控就是靠一批命令脚本着实不太优雅，Zabbix agent2 倒是好多了。
- Nightingale + Categraf：Nightingale 是一款开源的监控系统，Categraf 是 Nightingale 的采集器，支持 MySQL 的监控。Categraf 的 MySQL 监控插件除了可以采集 MySQL 基础指标，还可以自定义 SQL 语句采集业务指标。
MySQL 监控的关键指标
在监控 MySQL 时，需要关注以下关键指标：
| 监控类别 | 代表指标或信息 | 主要用途 |
|---|---|---|
| 连接相关 | Connections、Threads_connected、Aborted_connects、max_connections |
判断连接池、最大连接数和拒绝连接风险 |
| 查询性能 | QPS、Slow Queries、Performance Schema digest | 识别吞吐变化、慢 SQL 和高耗时语句 |
| 缓存性能 | InnoDB Buffer Pool Hit Rate | 判断是否频繁访问磁盘、是否需要关注缓冲池配置 |
| 锁和等待 | Lock Wait Time、Deadlocks | 定位事务竞争、锁等待和死锁问题 |
| 资源使用 | CPU、内存、磁盘 I/O | 判断瓶颈是否来自系统资源 |
| 复制状态 | Replication Delay | 判断主从复制是否落后，避免读到明显滞后的数据 |
连接相关
- 连接数（Connections）：当前连接数和最大连接数，以及 abort 的连接数。
查询性能
- 查询速率（Queries Per Second, QPS）：每秒执行的查询数。
- 慢查询数（Slow Queries）：执行时间超过阈值的查询数。
缓存性能
- InnoDB 缓冲池命中率（InnoDB Buffer Pool Hit Rate）：InnoDB 缓冲池的命中率。
锁和等待
- 锁等待时间（Lock Wait Time）：锁等待的时间。
- 死锁数（Deadlocks）：发生的死锁次数。
资源使用
- CPU 和内存使用率：MySQL 进程的 CPU 和内存占用。
- 磁盘 I/O：读写操作的性能，这个尤为关键。
复制状态
- 主从复制延迟（Replication Delay）：主从复制的延迟时间。
总结
MySQL 是非常常用的一款数据库，监控体系要同时服务于日常巡检、告警发现和故障排查。只看进程存活不够，只看慢查询也不够；更合理的做法是把内置命令、Performance Schema、慢查询日志和外部监控系统结合起来，持续观察连接、查询、缓存、锁、资源和复制状态。
通过 MySQL 自带的工具和开源监控工具，运维、DBA 和研发可以更直观地掌握数据库性能和状态，及时发现问题，并把告警、排障和容量规划放到同一套数据基础上。
FAQ
Q1：MySQL 监控最少应该覆盖哪些内容？
至少覆盖进程存活、错误日志、慢查询日志、连接数、QPS、慢查询数、InnoDB 缓冲池、锁等待、磁盘 I/O 和复制延迟。
Q2：SHOW STATUS 和监控系统是什么关系？
SHOW STATUS 适合现场查看服务器状态变量，监控系统适合持续采集、保存历史趋势和触发告警。两者不是替代关系，排障时通常要一起用。
Q3：为什么要关注磁盘 I/O？
MySQL 很多性能问题最终会落到读写延迟、缓冲池命中率和磁盘压力上。即使 SQL 本身没有明显变化，磁盘 I/O 也可能让查询响应变慢。
