MySQL Exporter 与 Grafana MySQL 数据源：我为什么选择前者

在 Grafana 添加数据源时，我看到了 MySQL，最初以为不装 exporter 也能得到数据库运行指标。实际上这两条路解决的问题不同：一条观察数据库运行情况，一条查询数据库里的业务数据。

两条路线怎样工作

MySQL Exporter 连接 MySQL，读取允许访问的状态和统计信息，转换为 Prometheus 指标。Prometheus 定时保存，Grafana 画历史趋势，告警规则也能使用这些指标。

Grafana 的 MySQL 数据源则让 Grafana 执行 SQL。例如业务表里保存了订单时间与金额，可以查询每日订单统计；它不会自动替我构建一整套连接数、InnoDB 和数据库健康监控。

本站主要目的是运维监控，因此采用 mysqld_exporter。需要业务报表时，再考虑只读账号与 Grafana MySQL 数据源，并控制查询成本。

独立账号比复用 root 更合适

本站 exporter 通过本机 Unix Socket 连接数据库，使用专门的数据库用户，限制最大连接数。实际授予 PROCESS、REPLICATION CLIENT 和 performance_schema 相关读取权限，没有为了省事给它 Typecho 业务表的任意读取权限。

权限应该与启用的 collector 匹配。某些采集功能需要额外权限，缺少权限时应先确认是否真的需要该指标，再补精确授权，不要直接把 ALL PRIVILEGES 当修复方案。

数据库凭据保存在 /etc/mysqld_exporter/my.cnf，文件限制访问，不公开密码。系统服务使用专用 Linux 用户；Linux 用户与 MySQL 用户是两个不同的身份体系。

三个适合先理解的指标

mysql_up{job="mysql"}
mysql_global_status_threads_connected{job="mysql"}
mysql_global_variables_max_connections{job="mysql"}

mysql_up 为 1 说明 exporter 此次能够完成基本数据库采集。连接数需要与 max_connections 一起看，单看“有十个连接”很难判断是否危险。

100 * mysql_global_status_threads_connected{job="mysql"}
/ on(job, instance) mysql_global_variables_max_connections{job="mysql"}

这个比例用于观察连接容量，不等于 CPU 或 SQL 执行速度。持续接近上限时，先检查连接泄漏、长连接和应用并发，再判断是否调整上限。盲目增加连接数也可能让内存压力更大。

遇到无数据怎么分层

先看 exporter 服务和日志，再看 up{job="mysql"}，随后看 mysql_up。前者失败偏向采集端点不可达；前者成功、后者失败则偏向数据库连接、权限或采集错误。最后才排查 Grafana 看板变量与指标名。

目前这套方案能帮助我观察趋势，但慢 SQL 的具体语句和执行计划仍需要慢查询日志与数据库工具，不能指望一个 exporter 自动给出所有性能答案。

连接比例的解释与边界

Threads_connected 包含 Sleep 状态连接，不等于正在执行 SQL 的并发数；还应结合 Threads_running、慢日志和应用连接池观察。用 job 与 instance 匹配分母，避免多实例混算。exporter 可以连数据库但部分 collector 仍可能报权限错误，应查日志和采集错误指标，mysql_up 为 1 不能保证所有 collector 都成功。

内容复核与修订：2026-10-29。实验示例与本站运行记录分别说明；原始归档日期保留。