mysql_exporter 启动报错主因是MySQL 8.0+禁用root@localhost socket登录且TCP未启用，应创建专用监控用户、确保skip-networking=OFF、bind_address兼容、显式传参配置文件，并验证Prometheus能采集到metrics。
mysql_exporter 启动就报 ERROR: unable to connect to MySQL instance
这大概是部署监控时遇到的第一个，也是最常见的“拦路虎”。问题根源很明确：mysql_exporter 默认试图用 root@localhost 去连接，但 MySQL 8.0 及更高版本，默认已经禁用了 auth_socket 插件方式的本地 root 登录，同时，TCP连接权限也可能没开。
怎么解决？别跟默认配置硬碰硬，试试下面这几步：
- 创建专用监控用户，别再折腾 root 了：
CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'safe_password'; GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost'; FLUSH PRIVILEGES;
- 确保 MySQL 配置允许 TCP 连接：检查
my.cnf里skip-networking是不是设成了OFF。另外，注意bind_address的坑：如果它绑定的是127.0.0.1（纯IPv4），而 exporter 连接时用了localhost（系统可能解析为IPv6或socket），就可能连不上。最稳妥的办法，连接时统一使用127.0.0.1:3306。 - 启动时显式传递配置文件，别依赖不靠谱的环境变量：
./mysqld_exporter --config.my-cnf=/etc/mysql_exporter.cnf
其中，/etc/mysql_exporter.cnf这个配置文件里，老老实实写上[client]段，填好用户名和密码。
Grafana 导入 MySQL Dashboard 后指标全空
仪表盘导入了，面板一片空白？先别急着怀疑模板有问题。十有八九，是 Prometheus 压根没抓到数据。这里有个常见的误解：能用 curl 访问到 mysql_exporter 的 metrics 端点（默认是 :9104/metrics），并不等于 Prometheus 就能正常采集。
排查思路可以这么走：
- 先看 Prometheus 的采集目标状态：打开 Prometheus 的 Web UI，进入
Status > Targets页面，找到 mysql_exporter 对应的 target。看看状态是不是UP。如果是DOWN，点进去看LastError，常见错误是 DNS 解析失败——比如配置里写了MySQL的容器服务名，但 Prometheus 跑在宿主机上，根本解析不了。 - 检查 mysql_exporter 的监听地址：确认启动参数
--web.listen-address绑定的是0.0.0.0:9104，而不是127.0.0.1:9104。后者只允许本机访问，容器外或者另一台主机上的 Prometheus 自然抓不到。 - 注意指标与 MySQL 版本的兼容性：很多 Dashboard 面板用的是
mysql_global_status_threads_connected这类指标。如果你的 MySQL 版本比较老（比如 5.6），部分状态变量可能不存在，图表自然就是空的。这时候，可以尝试换用兼容性更好的指标，例如mysql_info_schema_processlist_threads。
高并发下 mysql_exporter 拖慢 MySQL 响应
监控装上了，数据库却变慢了？这可不是危言耸听。mysql_exporter 默认每15秒就会去查询 information_schema 和 performance_schema。其中像 SELECT * FROM information_schema.PROCESSLIST 这样的查询，在连接数高达几千的场景下，可能会引发锁表或者触发全表扫描，成为性能瓶颈。
要避免监控反噬业务，可以这么调整：
- 关闭非必要的指标收集：启动 exporter 时，通过参数关掉一些重量级的收集项。
--collect.global_status=false --collect.info_schema.processlist=false
保留像global_variables、sla ve_status这类对性能影响较小的核心指标即可。 - 有连接监控的刚需？换个更高效的数据源：如果必须监控进程列表，可以考虑用
performance_schema.threads表来替代（前提是 MySQL 版本 ≥ 5.7，并且开启了performance_schema）。 - 拉长采集间隔：别把 Prometheus 的
scrape_interval设得太密。对于数据库监控，30秒甚至60秒的采集间隔，往往比默认的15秒对数据库更友好。mysql_exporter 本身不支持动态调整采集频率，节奏由 Prometheus 控制。
MySQL 主从延迟监控值始终为 0
主从延迟监控显示一直是0，就真的万事大吉了吗？未必。mysql_exporter 获取延迟数据主要依赖 SHOW SLA VE STATUS 中的 Seconds_Behind_Master 字段。但这个值在某些情况下会“说谎”：比如 IO 线程断开、SQL 线程卡住，或者在 GTID 模式下主从关系异常时，它都可能返回 NULL 或者 0，这并不代表真的没有延迟。
想要获得真实的延迟情况，得这么看：
- 先手动检查从库复制状态：连接到从库，执行
SHOW SLA VE STATUS\G。重点看Sla ve_IO_Running和Sla ve_SQL_Running两个字段是不是都为Yes。只要有一个不是，Seconds_Behind_Master的值就失去了参考意义。 - 在查询指标时增加过滤条件：使用
mysql_sla ve_status_seconds_behind_master这个指标时，应该加上复制状态正常的条件：mysql_sla ve_status_seconds_behind_master > 0 and mysql_sla ve_status_sla ve_io_running == 1 and mysql_sla ve_status_sla ve_sql_running == 1
这样筛选出来的延迟数据才靠谱。 - 考虑更底层的延迟指标：其实，更可靠的延迟衡量标准是主从之间 binlog position 的差值。不过，mysql_exporter 默认不直接提供这个指标。如果需要，可以通过自定义 query collector 来实现，编写SQL查询
master_log_file/position与relay_master_log_file/exec_master_log_pos的差值。
说到底，把监控配通只是第一步。真正的难点在于理解每一个指标背后，exporter 究竟查询了哪张系统表、可能触发了什么锁、又在哪个 MySQL 版本下会失效。监控数据一旦失真，带来的误导可能比没有监控更加危险。
