部署MySQL监控需先配置mysqld_exporter收集指标，再由Prometheus抓取，最后在Grafana可视化。核心步骤包括：创建专用监控用户并授予权限（SELECT on performance_schema, information_schema, sys；REPLICATION CLIENT；PROCESS）；正确设置DATA_SOURCE_NAME连接字符串；确保网络连通性及端口开放（MySQL 3306，exporter 9104）；将mysqld_exporter作为systemd服务运行；在Prometheus中添加job抓取exporter指标；Grafana导入模板或自定义仪表盘展示QPS、TPS、连接数、缓冲池命中率、慢查询、锁等待、复制延迟等关键指标；并通过PromQL设置基于阈值和持续时间的告警规则，结合Alertmanager实现有效通知。常见问题多源于权限不足、连接配置错误或防火墙限制，需通过日志排查。该体系实现对MySQL性能瓶颈的深度分析与提前预警。
利用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轻松采集到。
配置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_expor通过ter
terDATA_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的健康状况，还能在问题恶化前收到通知，从而实现更主动、更高效的数据库运维。
