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';<br>GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';<br>FLUSH PRIVILEGES;
- 确认 MySQL 配置没禁 TCP：检查
skip-networking是否为OFF，bind_address别写成127.0.0.1（IPv4）却让 exporter 用localhost（可能走 socket）——统一用127.0.0.1:3306最稳 - 启动时显式传参，别依赖环境变量出错：
./mysqld_exporter --config.my-cnf=/etc/mysql_exporter.cnf
，其中/etc/mysql_exporter.cnf写明[client]段用户名密码
Grafana 导入 MySQL Dashboard 后指标全空
不是模板问题，大概率是 Prometheus 没真正抓到数据 —— mysql_exporter 的 metrics 端点（默认 :9104/metrics）能 curl 通，不代表 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（后者容器外访问不到） - Dashboard 里很多 panel 用的是
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）在连接数几千时会锁表或触发全表扫描。
实操建议：
- 关掉非必要收集项：启动加参数
--collect.global_status=false --collect.info_schema.processlist=false
，保留global_variables、slave_status这些轻量指标 - 对 processlist 有刚需？改用
performance_schema.threads替代（需 MySQL ≥ 5.7，且performance_schema开启） - 调整采集间隔：Prometheus 的
scrape_interval别设太密，30 秒比 15 秒更友好；mysql_exporter 本身不支持动态调频，靠 Prometheus 控制节奏
MySQL 主从延迟监控值始终为 0
mysql_exporter 只能通过 SHOW SLAVE STATUS 拿 Seconds_Behind_Master，但这个值在 IO thread 断开、SQL thread 停滞、或者 GTID 模式下无主从关系时，会返回 NULL 或 0，不代表真没延迟。
实操建议：
- 先手动连从库执行
SHOW SLAVE STATUS\G，看Slave_IO_Running和Slave_SQL_Running是不是Yes；如果否，Seconds_Behind_Master就不可信 - 用
mysql_slave_status_seconds_behind_master这个指标时，加条件过滤：mysql_slave_status_seconds_behind_master > 0 and mysql_slave_status_slave_io_running == 1 and mysql_slave_status_slave_sql_running == 1
- 更可靠的延迟指标其实是主从间 binlog position 差值，但 mysql_exporter 不直接暴露；可自定义 query collector，写 SQL 查
master_log_file/position和relay_master_log_file/exec_master_log_pos差值
事情说清了就结束。真正难的不是配通，是理解每个指标背后查了哪张表、触发了什么锁、在什么 MySQL 版本下失效 —— 监控数据一旦失真，比没有还危险。
