mysql性能监控是运维调优的基础环节，必须依赖数据而非经验。常用工具分为命令行类（如top/htop、iostat、vmstat、show status、show processlist）和图形化系统（如prometheus+grafana、zabbix、pmm、mem）。应重点关注连接数、qps、tps、慢查询数、innodb缓冲池命中率、临时表创建次数、锁等待与死锁等指标。告警应基于历史数据设定阈值，优先关注关键问题，避免“告警疲劳”。监控数据建议保留60~90天，兼顾排障与趋势分析。
mysql的性能监控不是可有可无的事，而是运维和调优中非常基础的一环。光靠经验判断不够，得看数据说话。常用的做法是用一些工具收集指标、分析趋势，找出瓶颈所在。本文就聊聊几个常用的监控工具以及你该关注哪些关键指标。
1. 常用MySQL性能监控工具有哪些？
目前市面上主流的MySQL监控工具大致可以分为两类：命令行类工具 和 可视化监控系统。
-
命令行工具：
-
图形化监控系统：
- Prometheus + Grafana：组合使用，灵活度高，适合自建监控体系。
- Zabbix：功能全面，支持自动发现、告警机制，适合有一定规模的环境。
- Percona Monitoring and Management (PMM)：专为MySQL设计的开源监控平台，集成了Prometheus和Grafana，开箱即用。
- MySQL Enterprise Monitor（MEM）：官方商业产品，提供深度监控和预警功能。
如果你只是想快速上手，PMM是个不错的选择；如果已经有一套运维体系，那用Prometheus+Grafana更灵活。
2. MySQL监控应该重点关注哪些指标？
监控工具装好了，但不知道看什么等于白搭。下面这些指标是你日常排查问题时最常需要关注的：
-
连接数（Threads_connected）
- 过高的连接数可能意味着连接池配置不合理，或者有慢查询阻塞了连接释放。
-
QPS（Queries per second）与TPS（Transactions per second）
- QPS表示每秒处理的查询数量，TPS是事务处理量。这两个值波动大可能说明业务负载变化或存在异常SQL。
-
慢查询数量（Slow_queries）
- 慢查询是拖累性能的常见原因。建议开启慢查询日志，并定期分析。
-
InnoDB缓冲池命中率（InnoDB Buffer Pool Hit Ratio）
- 如果命中率低于95%，说明缓存不够用，可能需要增加innodb_buffer_pool_size配置。
-
临时表创建次数（Created_tmp_tables）
- 大量临时表会影响性能，尤其是当它们被创建在磁盘上时（查看Created_tmp_disk_tables）。
-
锁等待与死锁（Table_locks_waited、InnoDB_row_lock_waits）
- 高并发下锁竞争激烈会导致性能下降甚至服务不可用。
这些指标最好结合时间序列来看，单点数值意义不大。比如某个时刻QPS突然飙升，同时慢查询数也上升，那就要查当时执行的SQL有没有问题。
3. 如何设置告警？别等到出事才反应
监控的目的不只是“看看”，更重要的是提前发现问题。你可以根据历史数据设定阈值，一旦超过就触发告警。
常见的告警场景包括：
- 连接数超过最大允许连接的80%
- 每分钟慢查询数量超过一定数量
- 缓冲池命中率持续低于90%
- 主从延迟超过指定秒数（Seconds_Behind_Master）
不同的监控系统设置方式略有不同，但基本逻辑是一样的：选择指标 → 设置阈值 → 触发通知方式（邮件、钉钉、企业微信等）。
建议不要一开始就设置太多告警，容易造成“告警疲劳”。先挑几个最关键、最容易出问题的来监控，稳定后再逐步扩展。
4. 监控数据保存多久合适？
监控数据保留周期也是一个容易忽略的问题。短期数据（如最近7天）用于实时排障没问题，但如果要做长期趋势分析，至少要保留几个月的数据。
- PMM默认保留30天左右的数据，可以通过调整Prometheus配置延长。
- Zabbix 可以对接外部存储（如MySQL、TimescaleDB），实现长期存储。
- 自建系统可以根据需求定制保留策略。
一般来说，保留60~90天是一个比较合理的平衡点，既能满足排障需求，又不至于占用太多资源。
基本上就这些内容了。监控工具选对、指标看得准、告警设得合理，MySQL的运行状态就能掌握在自己手里，出了问题也不至于手忙脚乱。
