MySQL 生产流程监控咋选库？这俩常用工具手把手教你

摘要：今儿个咱聊聊 MySQL 生产流程监控里常用的俩库，Percona Toolkit 和 MySQL Exporter。好多朋友在监控 MySQL 的时候，老是犯难：不知道咋挑工具，装上了又不会看数据，出了问题也不知道咋优化。别慌，咱把这俩库掰开了揉碎了讲，搭配

MySQL 生产监控必备！Percona Toolkit 和 mysql Exporter 咋选咋用

MySQL 这俩库帮你搞定生产流程监控，治慢查询结合看全指标

MySQL 实战秘籍：用 Percona Toolkit 快速揪出慢 SQL

全方位监控 MySQL！MySQL Exporter 搭配 Prometheus 实战指南

今儿个咱聊聊 MySQL 生产流程监控里常用的俩库，Percona Toolkit 和 MySQL Exporter。好多朋友在监控 MySQL 的时候，老是犯难：不知道咋挑工具，装上了又不会看数据，出了问题也不知道咋优化。别慌，咱把这俩库掰开了揉碎了讲，搭配着实战代码和避坑技巧，保准你看完就能上手。

先看俩库啥区别：对比表格摆这儿了

二、Percona Toolkit 实战：专治慢查询这个大麻烦

好多朋友说，数据库时不时就卡一下，不知道啥原因。这时候pt-query-digest就派上大用场了，专门揪出拖后腿的慢 SQL。

1. 先把环境整好

首先得开慢查询日志，这是前提。打开 my.cnf，加上这几行：

保存后重启 MySQL。然后装Percona Toolkit，CentOS 用yum install percona-toolkit，Ubuntu 用apt-get install percona-toolkit，特简单。

2. 常用命令走一波

（1）分析全部慢查询，生成报告

打开报告，重点看这几块：

Overview：总共有多少慢查询，平均执行时间、锁时间啥的，先有个整体印象。

Top Queries by Time：按执行时间排前几名的 SQL，这些就是最拖后腿的，优先收拾它们。

Query Statistics：统计不同 SQL 的执行次数、总耗时、扫描行数，能看出哪些 SQL 虽然执行次数少，但每次都巨慢。

只看最耗时的 10 条 SQL

order-by后面可以跟不同的排序方式，比如Lock_time按锁时间排，Rows_examined按扫描行数排，按需选就行。

（3）分析某天的慢查询

比如分析 2023 年 10 月 1 号的慢查询，用这命令：

（4）把分析结果存数据库，方便后续查

先建表，执行这 SQL：

然后导入数据：

以后想查历史慢查询，直接查这张表就行，方便得很。

3. 实战优化：揪出慢 SQL，对症下药

举个例子，假设报告里有个 SQL 是这样的：

一看执行时间 2 秒，扫描了 10 万行。咋优化呢？

先看有没有索引，EXPLAIN一下，发现没用到索引，那就给customer_id和order_time加联合索引：

要是表里数据太多，加索引还是慢，可能就得考虑分表了，按时间分，比如按月分表，把老数据移到历史表。

三、MySQL Exporter 实战：全方位监控数据库健康

有的朋友想实时看数据库的 CPU、内存使用情况，看QPS、TPS的变化趋势，这就得靠 MySQL Exporter了，搭配Prometheus 和 Grafana，能画出各种漂亮的图表，数据变化一目了然。

1. 三步搭起监控系统

（1）创建专用用户

给这个用户必要的权限，让它能获取监控数据。

（2）启动 MySQL Exporter

推荐用 Docker，一行命令搞定：

collect后面可以加各种参数，按需收集不同的指标，比如collect.slave_status收集主从复制状态。

（3）启动 Prometheus 和 Grafana

Prometheus 配置文件prometheus.yml加上这行：

启动 Prometheus 后，访问http://localhost:9090，就能看到采集到的指标了。然后装 Grafana，导入 MySQL 监控模板（比如 ID 7362），就能看到各种漂亮的图表了。

2. 常用监控指标咋看

（1）性能指标，QPS（每秒查询数）：rate(mysql_global_status_queries[5m])，看这个指标能知道数据库的压力有多大，突然飙升可能就是有问题了。

事务多的时候，要注意数据库的处理能力。

连接数：MySQL_global_status_connections，连接数太多，可能会把数据库拖垮，得设置合理的连接上限。

（2）资源使用

CPU 使用率：100 - (avg by (instance) (rate(mysql_global_status_uptime[5m])) * 100)，CPU 长期高负载，得看看是不是有慢查询或者锁竞争。

内存使用率：(node_memory_MemTotal - node_memory_MemFree - node_memory_Buffers - node_memory_Cached) / node_memory_MemTotal * 100。这里得结合系统指标，MySQL Exporter 不直接采集系统内存，得靠 Node Exporter。

磁盘使用率：node_filesystem_use_percent{mountpoint="/"}，同样得靠 Node Exporter，磁盘满了可就麻烦了，数据都写不进去。

（3）慢查询和锁

慢查询数：increase(mysql_global_status_slow_queries[1h])，要是慢查询突然变多，赶紧用 pt-query-digest 分析。

锁等待数：sum(mysql_innodb_metrics_lock_waits)，锁等待多了，说明有事务在抢资源，得优化 SQL 或者调整事务逻辑。

3. 实战优化：指标报警早知道

好多朋友说，光看图表不够，得有报警，出问题了能及时知道。咱可以在 Prometheus 里配置告警规则，比如：

QPS 超过 5000，发警告：

连接数超过 1000，发错误报警：

配置好后，通过 Alertmanager 把报警发到微信、邮件啥的，出问题就能及时处理了。

四、常见问题咋解决？这几个坑别踩

1. 慢查询日志太大，占磁盘咋办？

定期归档，把老日志压缩存起来，比如每天凌晨用logrotate自动分割日志。

调整慢查询阈值，别把太小的查询也算进去，比如把long_query_time从 0.1 秒调成 0.5 秒，减少日志量。

2. MySQL Exporter 数据不准咋整？

检查用户权限，确保exporter用户有足够的权限获取数据。

看看配置参数，是不是漏了关键的采集项，比如主从环境得加上--collect.slave_status。

3. 报警太多，老是误报咋办？

调整告警阈值，别设得太严格，比如 CPU 使用率超过 80% 再报警，别 70% 就报。

加上for时间，比如持续 5 分钟超过阈值再报警，避免偶尔的波动触发报警。

五、总结：俩库咋选？看你需求来

简单说，要是你遇到具体的慢查询问题，想快速定位是哪个 SQL 拖后腿，就用 Percona Toolkit，特别是pt-query-digest，分分钟揪出问题 SQL。要是你想长期监控数据库的健康状况，看各种指标的趋势变化，及时发现潜在问题，那就用 MySQL Exporter，搭配 Prometheus 和 Grafana，搞一套可视化的监控系统。