可行，但必须先通过mysqld_exporter将mysql状态变量翻译为prometheus可拉取的指标格式；否则grafana无法绘图。常见错误是未配置dsn导致连接拒绝，需确认mysql监听地址、创建专用监控用户并显式指定.my.cnf配置文件。
MySQL性能监控用Prometheus+Grafana是可行的，但必须先解决一个前提：Prometheus本身不直接采集MySQL指标，得靠mysqld_exporter把MySQL的状态变量翻译成Prometheus能拉取的格式。跳过这步，Grafana里连一条曲线都画不出来。
为什么mysqld_exporter不能直接跑起来
常见错误是直接执行./mysqld_exporter就以为完事了，结果日志报dial tcp 127.0.0.1:3306: connect: connection refused——它默认连本地3306，但你的MySQL可能绑定了127.0.0.1以外的地址，或者开了skip-networking，又或者用户没权限查performance_schema。
实操建议：
- 确认MySQL监听地址：
SELECT @@bind_address, @@port;，如果返回*或0.0.0.0，说明支持远程连接；若为127.0.0.1，mysqld_exporter必须和MySQL同机部署 - 创建专用监控用户（别用root）：
CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'safe_password'; GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost'; - 启动时显式指定DSN：
./mysqld_exporter --config.my-cnf=.my.cnf，其中.my.cnf里写好[client]段的user/password/host/port
mysqld_exporter暴露的关键指标有哪些
它不是把所有SHOW STATUS值都上报，而是有选择地映射业务敏感项。比如mysql_up是健康探针，mysql_global_status_threads_connected对应当前连接数，mysql_global_status_questions是总查询量——这些才是你做QPS计算的基础。
注意几个易混淆点：
-
mysql_global_status_slow_queries只统计明确进入慢查询日志的语句，和long_query_time设置强相关，不是“执行慢就算” -
mysql_global_status_innodb_row_lock_waits这类InnoDB锁指标，只有启用innodb_stats_on_metadata=OFF等优化后才稳定可靠 - QPS要自己算：
rate(mysql_global_status_questions[1m])，别直接看mysql_global_status_questions原始值
Grafana里怎么避免“图表有了但看不懂”
很多团队导入现成Dashboard（比如mysql-mixin），结果满屏irate()和on(instance)聚合，根本不知道横轴单位是秒还是毫秒。核心是盯住三个业务可感知的维度：
- 响应时间：用
histogram_quantile(0.95, sum(rate(mysql_global_status_timer_wait{event_name=~"wait/io/file/.*"}[1m])) by (le))近似代替慢查询延迟（需开启Performance Schema） - 连接压力：把
mysql_global_status_threads_connected和max_connections配置值画在同一图层，用阈值线标出80%红线 - 磁盘IO瓶颈：重点看
mysql_global_status_bytes_received和mysql_global_status_bytes_sent的速率，突增往往意味着大结果集或未加LIMIT的查询在跑
别堆砌指标。一个Panel只回答一个问题：比如“此刻有没有连接数打满”，而不是“把10个状态变量全塞进一个折线图”。
真正难的不是配通数据链路，而是理解哪些MySQL状态变量在你的业务负载下会真实波动——比如OLAP场景下Sort_merge_passes飙升比Threads_created更有预警价值，而OLTP场景反过来。这需要你先用mysqladmin extended-status -r -i 1盯几分钟真实流量，再决定在Prometheus里盯哪几个数。
