关键在于配置最小权限监控账号并确保Prometheus正确抓取指标：创建exporter用户授予PROCESS、REPLICATION CLIENT、SELECT权限；DSN指向正确地址和端口；Prometheus targets需匹配job名与监听地址；瞬时指标需结合rate或max_over_time告警。
mysql_exporter 怎么装、怎么连上你的 MySQL 实例
关键不是“装”，是让 mysqld_exporter 能用合法账号连上 MySQL 并读取状态变量。它不连业务库，只查 information_schema 和 performance_schema，所以账号权限必须最小化但足够。
常见错误现象：ERROR: failed to ping mysqld: error connecting to master 或 Grafana 面板全空——大概率是账号没权限或网络不通。
- 创建专用监控用户（MySQL 8+）：
CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'safe_password' WITH MAX_USER_CONNECTIONS 3;<br>GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';
- 启动
mysqld_exporter时指定 DSN：./mysqld_exporter --config.my-cnf=/etc/mysql/exporter.cnf，其中exporter.cnf只存账号密码，别硬编码在命令行 - 如果 MySQL 在 Docker 或远程主机，确认
exporter用户 host 是'%'或对应 IP，且防火墙放行 3306（或 MySQL 实际端口）
Prometheus 抓不到 mysql_exporter 的指标？检查 targets 和 metrics_path
抓取失败不是因为 exporter 没跑，而是 Prometheus 配置里 endpoint 写错了，或者 exporter 启动后根本没暴露 /metrics 端点。
典型表现：prometheus_targets 页面显示 DOWN，错误信息是 Get "http://x.x.x.x:9104/metrics": dial tcp x.x.x.x:9104: connect: connection refused。
-
mysqld_exporter默认监听:9104，确认启动日志里有Listening on :9104，不是被其他进程占了端口 - Prometheus 的
scrape_configs中targets必须写成['host:9104']，不能漏掉端口；如果 exporter 加了--web.listen-address自定义地址，target 得同步改 - 别改
metrics_path——除非你真加了反向代理重写路径，否则保持默认/metrics即可
Grafana 导入 MySQL Dashboard 后数据全为零？核对 job 名和 label 匹配
Dashboard 里所有查询都依赖 Prometheus 查询语句里的 job="mysql" 这类 label，如果 Prometheus 配置的 job 名不是 mysql，面板就查不到任何数据。
最常踩的坑：复制粘贴别人的 prometheus.yml，但没改自己的 job 名，或者加了额外的 static_configs 导致重复 target。
- 进 Prometheus 表达式浏览器，输入
mysql_up，看返回结果的 label 里job值是什么，比如是mysql-prod，那所有面板里的查询就得把job="mysql"改成job="mysql-prod" - 检查
mysqld_exporter启动参数有没有加--web.telemetry-path，改了路径会导致 Prometheus 抓不到指标（虽然 exporter 日志显示正常） - 部分旧版 Dashboard（如 7362）用
instance区分多实例，如果你只有一台 MySQL 却用了多实例模板，avg by(instance)会因无匹配 label 返回空
为什么 mysql_global_status_threads_connected 突增却没报警？检查采集频率和瞬时指标特性
这个指标是瞬时值，不是累计值。Prometheus 默认每 15s 抓一次，如果连接数在两次采集之间暴涨又快速回落，图表看起来就是平的，告警规则也容易漏判。
真实场景中，短连接风暴（比如应用重启、定时任务集中发起连接）往往持续不到 15 秒，靠单点指标根本捕不住。
- 改 Prometheus 抓取间隔到
scrape_interval: 5s（仅限关键实例，别全局改，会压垮 Prometheus） - 告警规则别直接用
mysql_global_status_threads_connected > 1000，改用rate(mysql_global_status_threads_connected[1m]) > 0结合max_over_time查峰值 - 更靠谱的是结合
mysql_global_status_aborted_connects和mysql_global_status_threads_created，这两个能反映连接异常和新建连接压力
真正难监控的不是“连得上”，是“连得怪”——比如大量短连接 + 高 Aborted_connects + wait_timeout 被触发，这种组合信号比单个指标更有诊断价值。别只盯着 Dashboard 美不美观。
