正文

网站突然变慢数据库报警时 5款MySQL性能监控工具实测对比帮你快速定位慢查询问题

/0 浏览量
0903

网站突然变慢数据库报警时 5款MySQL性能监控工具实测对比帮你快速定位慢查询问题

凌晨三点，你的手机震了。

不是闹钟，是报警。某个核心业务系统的数据库CPU直接飙到98%，响应时间卡在半分钟以上。运营群里已经炸锅了——”用户投诉刷不出页面了”，”订单下不了单了”。

你连上服务器，习惯性地打开Navicat，心里默念”千万别是昨晚那个新上的SQL”。

但问题不止一个。你知道慢查询可能在哪，但具体是哪个索引失效了、是锁竞争还是连接数爆了，你没法一眼看穿。这时候，工具就是你的眼睛。

下面我要聊的，是五款我这些年真正在 production 环境里跑过、也踩过大坑的MySQL监控工具。不会跟你背书什么是功能、什么是优点，而是告诉你——在数据库真的出事了的时候，哪个工具能救你，哪个会让你更急。

一、Percona Monitoring and Management（PMM）

“开源监控的天花板，装上就不想换。”

PMM是Percona公司做的，基于Prometheus + Grafana，是真正的生产级开源方案。我2019年在一家电商公司第一次用它，到现在三年多，它一直是我们的主力监控平台。

为什么选它：

第一，它不用你在每个MySQL实例上装agent。PMM Server会自动通过MySQL Exporter采集指标——QPS、TPS、连接数、InnoDB Buffer Pool命中率、慢查询日志、复制延迟，全都有。你只需要把Exporter部署在目标机器上，PMM会自动发现并收集。

第二，Grafana仪表盘的丰富程度。官方提供了数十个预置面板，从”Overview”到”Innodb Row Operations”到”MySQL Top Query by Time”，开箱即用。你不用自己写查询语句来画图。

第三，它能把慢查询日志直接解析出来，按响应时间排序，按数据库、按表、按用户聚合。这对定位问题非常有帮助。

实测场景——

有一回，某业务线的订单查询接口响应时间从200ms飙升到3秒。我们打开PMM的”Top Queries by Time”面板，直接看到一条重复执行的SELECT，平均耗时2.8秒，每次执行都锁住了一批行。

-- PMM慢查询面板里直接展示的SQL
SELECT o.*, u.name 
FROM orders o 
JOIN users u ON o.user_id = u.id 
WHERE o.status = 3 
  AND o.created_at > '2024-01-01'
ORDER BY o.created_at DESC
LIMIT 50;

这条SQL的问题在于，status字段是枚举值，但索引设计时只建了(created_at)，复合索引没覆盖status，导致全索引扫描+回表。加上没有分页优化，每次查询都读了几万行。

PMM里的关键指标面板值得重点关注：

  • MySQL Overview —— 一眼看出CPU、连接数、QPS的异常波动
  • MySQL Top Queries —— 按执行时间、锁等待时间排序的SQL
  • MySQL InnoDB Row Operations —— 能看到行锁竞争的根源
  • MySQL Replication —— 主从延迟超过阈值会直接标红

缺点也得说实话：

PMM Server本身占资源，建议单独部署在一台独立机器上。另外，它的Alert规则虽然支持Webhook推送，但配置起来需要一定的Prometheus语法基础，不是点几下就能用的。如果你完全没接触过Grafana，可能需要花一两天熟悉。

二、MySQL Workbench（自带性能监控功能）

“最熟悉的陌生人，别忽视Oracle家的自带工具。”

MySQL Workbench是Oracle官方出的图形化工具，大家最常用的功能是建库建表、写SQL。但很少有人知道，它在”Server Administration”模块里内置了Performance Schema的可视化功能。

它适合的场景：

你不是在大规模集群，只有一两台MySQL实例，不想折腾复杂的监控系统，只想快速看一眼——现在CPU占用高不高、有没有长时间执行的SQL、InnoDB Buffer Pool够不够用。

实操步骤——

打开Workbench，连接到你的MySQL实例，然后点击左侧菜单的 Server Status，会弹出四个标签页：

  1. Processes —— 当前所有连接，能看到每条SQL在做什么，执行了多久，是否被锁
  2. CPU —— 实时CPU使用率曲线
  3. Memory —— 内存使用情况，包括Buffer Pool大小和命中率
  4. Network —— 网络流量

关键操作：

看到某个进程长时间挂起，右键点击它，可以选择”Kill Process”。这在排查慢查询时非常直接。

局限：

Workbench的监控粒度太粗，只能看实时的、短期的数据。如果你想追踪”昨天下午两点到底发生了什么”，它没办法回放。而且随着实例数量增加，手动一个个连上去看会变得非常痛苦。它更适合临时救火，不适合长期监控。

三、MySQL Enterprise Monitor

“Oracle官方企业的监控工具，贵有贵的道理。”

如果你公司用的是Oracle MySQL Enterprise版本，这个工具是捆绑的。它和PMM不一样，PMM是Prometheus生态，这个则是Oracle自己的一整套监控方案。

它的核心能力：

  1. SQL Profile分析 —— 它会基于执行计划对每条SQL打分，告诉你是”好SQL”还是”有问题SQL”。这个评分系统是基于历史数据训练的，不是简单的慢查询过滤。

  2. Alert Baseline —— 它能学习你系统的正常行为基线。比如你的数据库平时QPS在500左右，周末会低一些。如果某天凌晨突然飙升到2000，它会判断这是异常，而不是简单地跟固定阈值比较。

  3. Schema设计建议 —— 这个功能很有意思，它会扫描你的表结构，指出哪些索引是重复的、哪些字段类型可以优化、哪些查询可以改写以获得更好的执行计划。

一个真实的案例——

某金融系统有一批定时任务，每天凌晨执行对账SQL。执行时间从15分钟慢慢增加到40分钟，但没有报警，因为执行本身是”正常结束”的。

MySQL Enterprise Monitor的SQL Profile功能标记了这批SQL，显示它们的”成本系数”在持续上升。点开详情，发现是因为某张对账表的索引在一次DDL变更后失效了，导致全表扫描。如果没有这个工具，这种缓慢的性能退化几乎无法被发现。

缺点：

  • 仅限Oracle MySQL Enterprise版本，Community版本用不了
  • 部署复杂，需要安装Agent和Central Server
  • 授权费用昂贵，中小企业基本不考虑

四、Adminer + 慢查询日志手动分析

“有时候最简单的方法，反而是最有效的。”

我之所以把”手动分析”也算作一种工具，是因为在很多紧急情况下，监控平台本身可能就挂了，或者你根本没来得及配置。这时候，你只有三样东西：终端、MySQL命令行、和慢查询日志。

慢查询日志的位置：

# 查看慢查询日志路径
mysql -u root -p -e "SHOW VARIABLES LIKE 'slow_query_log_file';"

# 或者直接在配置文件中确认
grep -r 'slow_query_log' /etc/mysql/

实时追踪正在执行的SQL——

-- 查看所有正在运行的进程
SHOW FULL PROCESSLIST;

-- 过滤出执行时间超过10秒的SQL
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, LEFT(INFO, 100) AS SQL_SHORT
FROM information_schema.PROCESSLIST
WHERE COMMAND != 'Sleep'
  AND TIME > 10
ORDER BY TIME DESC;

这个查询能帮你快速揪出”罪魁祸首”。如果看到某条SQL已经跑了超过30秒，而它的STATE是Sending data或Waiting for lock，那就是它了。

用mysqldumpslow解析慢查询日志——

# 按查询次数排序
mysqldumpslow -s c -t 10 /var/log/mysql/slow.log

# 按平均响应时间排序
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log

# 只看包含特定关键词的SQL
mysqldumpslow -s t -t 5 -g "ORDER BY" /var/log/mysql/slow.log

用EXPLAIN定位问题——

拿到慢SQL之后，第一件事是加EXPLAIN：

EXPLAIN SELECT o.*, u.name 
FROM orders o 
JOIN users u ON o.user_id = u.id 
WHERE o.status = 3 
  AND o.created_at > '2024-01-01'
ORDER BY o.created_at DESC
LIMIT 50;

EXPLAIN输出里最值得关注的字段：

  • type：如果是ALL，说明全表扫描，有问题
  • key：实际使用的索引，如果是NULL，说明没用上索引
  • rows：预估扫描行数，这个数字越大越危险
  • Extra：如果看到Using filesort或Using temporary，说明查询效率很低

手动分析的真实体感：

说实话，手动分析是最考验功力的，但也是最直接的。PMM再好用，它的告警延迟、数据保留周期都是有限制的。当数据库真的在生产环境出问题、而你手里只有这台服务器的时候，SHOW PROCESSLIST 和 mysqldumpslow 就是你的救命稻草。

五、阿里云RDS性能优化（PMO）/ 腾讯云TDSQL监控

“云数据库的自带监控，别嫌它不够深，关键时刻真能救命。”

如果你用的是云数据库（阿里云RDS、腾讯云CDB、AWS RDS），云厂商自带的监控平台其实是第一道防线。我见过太多人，云RDS报警了，他们第一反应是去连数据库看，结果因为网络抖动连不上，浪费了大量时间。

云监控能帮你做什么：

以阿里云RDS为例，控制台的”性能优化”页面提供了以下关键指标：

  • 实时CPU使用率、内存使用率
  • 连接数、慢查询数
  • IOPS使用率
  • 锁等待次数
  • SQL洞察（按时间轴展示的SQL执行热力图）

SQL洞察尤其有用——

它是一个时间轴视图，你可以看到每天哪个时段SQL最密集、哪些SQL最慢。更重要的是，它能直接给你优化建议，比如”建议为某张表添加索引”、”某条SQL的扫描行数异常高”。

实操案例：

某跨境电商平台的数据库在双11期间出现间歇性卡顿。通过云监控的SQL洞察，我们发现某个时段的慢查询数量突然激增，而且集中在同一批订单查询SQL上。进一步分析发现，这些SQL的扫描行数从平时的几百行变成了几十万行——显然是某个索引失效了。

云监控里还有一个隐藏功能叫”SQL调优”，它会自动分析慢查询，并给出ALTER TABLE的语句建议。虽然不建议直接执行，但可以作为参考。

对比总结：什么情况下用哪个

工具 适合场景 部署难度 数据保留 推荐指数
PMM 生产环境主力监控，多实例 中 长（取决于Prometheus配置） ⭐⭐⭐⭐⭐
MySQL Workbench 临时排查、单实例快速诊断 低 实时，无历史 ⭐⭐⭐
MySQL Enterprise Monitor Oracle企业版用户，需要深度分析 高 长 ⭐⭐⭐⭐
手动分析（SHOW PROCESSLIST + mysqldumpslow） 紧急救火、监控不可用 低 无 ⭐⭐⭐⭐⭐
云监控（SQL洞察） 云数据库用户，快速定位 低 中 ⭐⭐⭐⭐

写到这里，想说几句掏心窝的话

数据库出问题的时候，人的第一反应往往是慌。尤其是凌晨被报警叫醒，脑子还没清醒的情况下，最容易犯的错误就是——盲目重启、盲目加配置、盲目删数据。

我见过最惨的一次，有人看到CPU 98%，第一反应是systemctl restart mysql。重启之后数据库是下来了，但问题没解决，而且重启期间业务完全中断，造成的损失比慢查询本身大十倍。

正确的姿势是：先定位，再动手。

用工具看清楚现在发生了什么，是哪条SQL、哪个表、哪种锁，然后再决定是加索引、改配置、还是kill进程。工具只是辅助，真正重要的是你排查问题的思路。

这五款工具，我建议至少熟练使用其中两款——PMM用于日常监控，手动分析用于紧急救火。其他的，看你的技术栈和预算选择即可。

祝你永远用不上这些工具，但如果那一天真的来了，希望它们能帮到你。

-- 展开阅读全文 --