利用Prometheus和Grafana监控MySQL数据库性能，核心在于部署一个MySQL Exporter来收集数据库的各种指标，然后让Prometheus抓取这些数据，最终在Grafana中进行可视化和报警。这套组合拳能让你对MySQL的运行状况一览无余，及时发现并解决潜在的性能问题。
解决方案要搭建这套监控体系，我们需要依次完成几个关键步骤。这不仅仅是技术上的部署，更是一种对数据驱动型运维的思维转变。
首先，部署
mysqld_exporter。这是Prometheus生态中专门用于MySQL监控的工具。你需要在每个需要监控的MySQL实例所在的服务器上安装并运行它。通常，我会选择从GitHub下载预编译的二进制文件，解压后直接运行。为了让
mysqld_exporter能够访问MySQL的性能数据，你需要在MySQL中创建一个专门的用户，并赋予其只读的权限，例如
GRANT SELECT ON performance_schema.* TO 'exporter'@'localhost' IDENTIFIED BY 'your_password';此外，为了获取更全面的指标，比如InnoDB的统计信息，还需要授予对
information_schema和
sys数据库的
SELECT权限。配置时，通过
DATA_SOURCE_NAME环境变量或命令行参数指定连接字符串，比如
user:password@(hostname:port)/。我个人习惯把它作为一个systemd服务来管理，确保它能随系统启动并保持运行，这样也方便日志管理和状态检查。
其次，配置Prometheus抓取
mysqld_exporter的指标。在Prometheus的配置文件
prometheus.yml中，你需要添加一个新的
scrape_config。这部分告诉Prometheus去哪里找
mysqld_exporter暴露的HTTP接口。通常，
mysqld_exporter默认监听
9104端口。一个典型的配置片段可能看起来像这样：
- job_name: 'mysql'
static_configs:
- targets: ['your_mysql_server_ip:9104']
labels:
instance: 'mysql-primary' # 给实例一个有意义的标签 别忘了重启Prometheus服务，让新的配置生效。我发现很多人会在这里犯错，忘记重启服务，然后疑惑为什么看不到数据。Prometheus的Web UI（通常在
9090端口）可以帮助你检查
Targets状态，确认是否成功抓取到
mysqld_exporter的指标。
最后，在Grafana中构建仪表盘。这是将原始数据转化为有意义图表的关键一步。你需要在Grafana中添加Prometheus作为数据源，这很简单，只需要指定Prometheus的URL。之后，你可以选择导入社区已经共享的MySQL仪表盘模板（例如，Grafana Labs上有很多优秀且成熟的模板，ID如7362或10705就非常流行），这些模板通常包含了丰富的图表，覆盖了MySQL的各种核心性能指标。当然，如果你有特定的监控需求，也可以从零开始，根据Prometheus抓取到的指标（比如
mysql_global_status_queries_total、
mysql_global_status_innodb_buffer_pool_reads_total等）构建自己的图表。我通常会从导入一个通用模板开始，然后根据实际情况调整或添加一些我特别关心的指标，比如特定业务查询的QPS或慢查询计数。 核心MySQL性能指标有哪些，以及如何通过Prometheus进行采集？
在我看来，监控MySQL不仅仅是看它有没有“活着”，更重要的是看它“活得好不好”，以及在面临压力时表现如何。因此，选择合适的性能指标至关重要。我通常会关注以下几类核心指标：
连接数（Connections）：
mysql_global_status_threads_connected
和mysql_global_status_threads_running
。前者表示当前打开的连接数，后者表示正在执行查询的连接数。过高的连接数可能导致MySQL资源耗尽，而运行连接数长时间居高不下则暗示着查询效率低下或并发瓶颈。mysqld_exporter
会直接采集这些数据。查询吞吐量（QPS/TPS）：
mysql_global_status_queries_total
和mysql_global_status_com_commit
、mysql_global_status_com_rollback
。QPS（每秒查询数）是衡量数据库活跃度的直接指标，而TPS（每秒事务数）则反映了事务处理能力。通过计算这些指标的速率（rate()
函数在Prometheus中非常有用），我们可以得到实时的QPS和TPS。缓冲池命中率（Buffer Pool Hit Rate）：InnoDB缓冲池是MySQL性能的关键。我主要关注
mysql_global_status_innodb_buffer_pool_reads_total
和mysql_global_status_innodb_buffer_pool_read_requests_total
。理想情况下，命中率应该非常高（99%以上），如果持续下降，说明MySQL正在频繁地从磁盘读取数据，这通常是性能瓶颈的信号。慢查询（Slow Queries）：
mysql_global_status_slow_queries_total
。慢查询是性能杀手，它们的数量激增往往意味着某些SQL语句需要优化，或者索引失效。这个指标可以直接告诉你是否存在这类问题。锁与等待（Locks & Waits）：
mysql_global_status_innodb_row_lock_current_waits
和mysql_global_status_innodb_row_lock_time_avg
。高并发场景下，锁竞争是常态，但如果等待时间过长或等待数量过多，就可能导致事务阻塞，影响整体性能。mysqld_exporter
会暴露这些来自information_schema
和performance_schema
的指标。复制延迟（Replication Lag）：对于主从架构，
mysql_slave_status_seconds_behind_master
至关重要。这个指标直接反映了从库与主库的数据同步延迟，过高的延迟可能导致数据不一致或读写分离失效。
mysqld_exporter通过连接到MySQL实例，查询
SHOW GLOBAL STATUS、
SHOW ENGINE INNODB STATUS、
SHOW SLAVE STATUS以及
information_schema和
performance_schema中的各种视图来获取这些指标，然后以Prometheus可识别的格式暴露出来。所以，只要
mysqld_exporter配置正确，这些核心指标都能被Prometheus轻松采集到。
PIA
全面的AI聚合平台，一站式访问所有顶级AI模型
226
查看详情
配置mysqld_exporter时，有哪些常见的权限和连接问题需要注意？
说实话，我在配置
mysqld_exporter的时候，最常遇到的问题就是权限和连接相关的。这些小细节往往最容易被忽视，却能让你抓狂好一阵子。
1. MySQL用户权限不足： 这是最常见的“拦路虎”。
mysqld_exporter需要一个MySQL用户来连接数据库并查询各种状态信息。如果这个用户的权限不足，它就无法获取到所有需要的指标，或者根本无法连接。
-
问题表现：
mysqld_exporter
的日志中会报错，提示权限不足，或者Prometheus抓取到的指标数量异常少，很多关键指标缺失。 -
解决策略： 确保你创建的用户拥有以下权限：
SELECT
权限在performance_schema.*
、information_schema.*
和sys.*
上。performance_schema
提供了大量的运行时统计信息，information_schema
包含元数据，sys
库则聚合了许多有用的性能视图。- 对于某些高级指标，例如InnoDB的死锁信息，可能需要
PROCESS
权限。 - 如果你要监控复制状态，还需要
REPLICATION CLIENT
权限。 - 一个比较通用的授权语句（仅限监控，不建议用于生产写操作）：
CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'your_strong_password'; GRANT SELECT ON *.* TO 'exporter'@'localhost'; # 广度，但通常建议更精细 -- 或者更精细的授权： -- GRANT SELECT ON performance_schema.* TO 'exporter'@'localhost'; -- GRANT SELECT ON sys.* TO 'exporter'@'localhost'; -- GRANT SELECT ON information_schema.* TO 'exporter'@'localhost'; -- GRANT REPLICATION CLIENT ON *.* TO 'exporter'@'localhost'; -- GRANT PROCESS ON *.* TO 'exporter'@'localhost'; FLUSH PRIVILEGES;
- 我通常会先用一个拥有
SELECT ON *.*
的账户测试，确认功能正常后，再逐步收紧权限，找到最小权限集。
2.
DATA_SOURCE_NAME配置错误：
mysqld_exporter通过
DATA_SOURCE_NAME环境变量或命令行参数来获取MySQL的连接信息。格式通常是
user:password@(hostname:port)/。
-
问题表现：
mysqld_exporter
启动失败，或者日志显示无法连接到MySQL服务器。 -
解决策略： 仔细检查连接字符串中的用户名、密码、主机名和端口是否正确。特别注意主机名，如果是本地连接，
localhost
或127.0.0.1
通常都可以，但如果MySQL配置了只监听特定IP，或者mysqld_exporter
运行在不同的服务器上，就需要填写正确的IP地址。
3. 网络连接问题： 防火墙、网络策略或MySQL绑定地址限制都可能导致
mysqld_exporter无法连接到MySQL服务器。
-
问题表现：
mysqld_exporter
日志显示连接超时或拒绝连接。Prometheus也无法抓取到mysqld_exporter
的指标。 -
解决策略：
-
防火墙： 确保MySQL服务器的
3306
端口（或自定义端口）对mysqld_exporter
所在的主机开放。同时，也要确保mysqld_exporter
暴露的9104
端口对Prometheus服务器开放。 -
MySQL绑定地址： 检查MySQL的
my.cnf
配置文件中的bind-address
设置。如果设置为127.0.0.1
，则MySQL只允许本地连接。如果你想从其他主机连接，需要将其设置为0.0.0.0
（允许所有IP连接，但安全性较低，建议配合防火墙）或具体的服务器IP。 -
网络连通性： 在
mysqld_exporter
所在的主机上，尝试使用telnet your_mysql_server_ip 3306
或mysql -h your_mysql_server_ip -u exporter -p
命令，手动测试与MySQL的连接。
-
防火墙： 确保MySQL服务器的
4.
mysqld_exporter端口冲突或未启动：
-
问题表现： Prometheus无法抓取到
mysqld_exporter
的指标，Targets
页面显示connection refused
或timeout
。 -
解决策略：
- 确认
mysqld_exporter
是否已成功启动，并且没有其他服务占用9104
端口。可以使用netstat -tulnp | grep 9104
命令检查。 - 查看
mysqld_exporter
的启动日志，确认是否有报错信息。
- 确认
处理这些问题时，我通常会从检查日志开始，日志文件是最好的“侦探”。
如何利用Grafana仪表盘深度分析MySQL性能瓶颈，并设置有效的告警规则？Grafana不仅仅是展示数据的工具，它更是一个强大的分析平台。要深度分析MySQL性能瓶颈，我们需要学会“阅读”仪表盘，并结合Prometheus的查询语言（PromQL）设置有意义的告警。
1. 深度分析瓶颈：
- 从宏观到微观： 我通常会从一个概览仪表盘开始，比如查看QPS、TPS、连接数等整体指标。如果看到某个指标出现异常（比如QPS突然下降，或连接数激增），我就会开始深入挖掘。
- 关联性分析： 性能问题往往不是单一指标引起的。例如，如果看到慢查询计数突然增加，我会立即去查看CPU使用率、IOPS和InnoDB缓冲池命中率。如果CPU和IOPS也同时飙升，而缓冲池命中率下降，那很可能就是因为慢查询导致了大量的磁盘IO，进而拖慢了整个数据库。
- 时间段对比： Grafana的时间范围选择功能非常强大。我会对比问题发生前后的数据，或者与历史正常运行时期的数据进行对比。例如，某个查询在平时执行很快，但在高峰期却变慢了，这可能意味着资源竞争或锁等待。
-
利用PromQL进行即时查询： 仪表盘上的图表固然方便，但Prometheus的Explore功能配合PromQL才是真正的利器。当仪表盘无法提供足够细节时，我会在Explore中手动构建查询，例如，查询特定表的行锁等待时间
mysql_global_status_innodb_row_lock_time_avg{instance="mysql-primary", schema="your_db"}，或者查看特定SQL语句的执行次数（如果你的mysqld_exporter
配置了采集query_digest）。 - 日志与监控结合： 监控数据告诉你“什么”出了问题，而MySQL的错误日志、慢查询日志则告诉你“为什么”以及“谁”出了问题。将Grafana上的时间点与日志文件中的时间戳对齐，能帮助你快速定位根本原因。
2. 设置有效的告警规则：
告警的目的是在问题变得严重之前通知你，而不是等系统崩溃了才收到通知。我倾向于设置基于阈值和趋势的告警。
Prometheus Alertmanager： Prometheus本身负责收集数据和评估告警规则，而Alertmanager则负责对告警进行去重、分组、路由和发送通知（邮件、Slack、Webhook等）。你需要配置好Alertmanager，并让Prometheus知道它的地址。
-
告警规则（
alert.rules.yml
示例）：groups: - name: mysql_alerts rules: - alert: HighMySQLConnections expr: sum(mysql_global_status_threads_connected) by (instance) > 100 # 假设100是你的阈值 for: 5m # 持续5分钟以上 labels: severity: warning annotations: summary: "MySQL实例 {{ $labels.instance }} 连接数过高" description: "当前连接数达到 {{ $value }}，可能导致性能下降或连接拒绝。" - alert: LowInnoDBBufferPoolHitRate expr: 100 * (1 - sum(rate(mysql_global_status_innodb_buffer_pool_reads_total[5m])) by (instance) / sum(rate(mysql_global_status_innodb_buffer_pool_read_requests_total[5m])) by (instance)) < 95 for: 10m labels: severity: critical annotations: summary: "MySQL实例 {{ $labels.instance }} InnoDB缓冲池命中率过低" description: "缓冲池命中率已降至 {{ $value }}%，可能存在大量磁盘I/O，请检查慢查询或内存配置。" - alert: MySQLReplicationLag expr: mysql_slave_status_seconds_behind_master > 60 # 超过60秒延迟 for: 2m labels: severity: critical annotations: summary: "MySQL实例 {{ $labels.instance }} 复制延迟过高" description: "从库与主库延迟已达 {{ $value }} 秒，请检查复制状态。"-
expr
： 定义触发告警的PromQL查询。 -
for
： 告警条件需要持续多长时间才会被触发。这能有效减少瞬时波动的误报。 -
labels
： 用于Alertmanager对告警进行分类和路由。severity
标签很常用。 -
annotations
： 提供告警的详细信息，帮助接收者快速理解问题。我通常会在这里加入一些建议的排查步骤。
-
告警阈值的设定： 这通常需要结合历史数据和业务需求。一个“高”连接数对一个小型应用可能意味着50，对一个大型应用可能意味着500。我会观察数据库在正常负载下的行为，然后设置一个略高于正常峰值的阈值。对于关键指标，我可能会设置多级告警（warning和critical），以便有时间提前介入。
通过这套组合拳，我们不仅能实时掌握MySQL的健康状况，还能在问题恶化前收到通知，从而实现更主动、更高效的数据库运维。
以上就是如何利用Prometheus和Grafana监控MySQL数据库性能指标的详细内容，更多请关注知识资源分享宝库其它相关文章！
相关标签： mysql word git github 防火墙 工具 ai 路由 环境变量 win 常见问题 sql mysql 架构 for select 字符串 命令行参数 接口 并发 alert github 数据库 http ui prometheus grafana 大家都在看： MySQL内存使用过高（OOM）的诊断与优化配置 MySQL与NoSQL的融合：探索MySQL Document Store的应用 如何通过canal等工具实现MySQL到其他数据源的实时同步？ 使用Debezium进行MySQL变更数据捕获（CDC）实战 如何设计和优化MySQL中的大表分页查询方案
发表评论:
◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。