MySQL迁移后mysqld_exporter连不上，根本原因是连接凭据未同步更新：需检查--config.my-cnf、--mysql.address、SSL配置及MySQL用户权限；Prometheus需手动更新scrape_configs中targets；Grafana“no data”多因标签不匹配；mysql_up=1但慢查询为0，是performance_schema消费者未启用或exporter未配置对应collect参数。
MySQL迁移后 mysqld_exporter 连不上怎么办
迁移后最常见的是 mysqld_exporter 启动失败或指标为空，根本原因是它仍连着旧实例的地址、账号或 TLS 配置不匹配。不是 exporter 本身坏了，而是连接凭据没同步更新。
检查步骤：
- 确认 mysqld_exporter 启动时用的 --config.my-cnf 文件（如有）是否指向新库的 .my.cnf；
- 若用命令行参数传 --web.listen-address 和 --mysql.address，需重写为新库 IP + 端口，比如 --mysql.address=10.20.30.40:3306；
- 新库若启用了 require_secure_transport，则必须给 mysqld_exporter 配 --mysql.ssl-mode=REQUIRED 并挂载 CA 证书路径；
- 检查 MySQL 用户权限：该用户至少要有 PROCESS、REPLICATION CLIENT、SELECT（对 performance_schema 和 information_schema）。
Prometheus 的 scrape_configs 该怎么改
迁移后 Prometheus 自己不会自动发现新地址，必须手动更新配置里的 static_configs 或服务发现逻辑。漏改这里，指标就彻底断了，但日志里往往只报 “context deadline exceeded”，容易误判为网络问题。
关键修改点：
- 找到 scrape_configs 下对应 MySQL 的 job，把 targets 列表从旧 exporter 地址（如 ["192.168.1.10:9104"]）换成新地址；
- 如果用了 DNS 名称（如 ["mysqld-exporter-prod:9104"]），确认 Kubernetes Service 或 DNS 记录已指向新 Pod / 主机；
- 若启用了 relabel_configs 做实例打标（如用 __meta_kubernetes_pod_node_name），迁移后节点名变了，可能影响 Grafana 查询中的筛选逻辑，建议加一条 replacement 固定 instance 标签值；
- 修改后别忘了 curl -X POST http://prometheus:9090/-/reload 或发 SIGHUP，否则配置不生效。
Grafana 中的 MySQL Dashboard 报 “no data” 怎么排查
不是模板问题，大概率是数据源标签对不上。迁移后 MySQL 实例的 instance、job、甚至 exported_instance 标签值都可能变化，而 Dashboard 的变量查询（如 label_values(mysql_global_status_uptime, instance)）会因标签缺失直接返回空。
快速验证方法：
- 在 Prometheus 表达式浏览器里直接输入 count(mysql_global_status_uptime)，看是否有结果；
- 如果有，执行 mysql_global_status_uptime{job="mysql"}，确认返回的 series 是否带预期的 instance 标签；
- 如果没有，说明 scrape 失败，回退查上一步；
- 如果有但 Dashboard 仍无数据，打开 Dashboard 的 “Variables” 设置，检查每个变量的查询语句是否还依赖旧标签名（比如硬编码了 mysql_old_prod 这类 label_value）；
- 尤其注意 exported_instance —— 如果 exporter 开了 --web.enable-admin-api 或用了 mysqld_exporter v0.15+ 的 --collect.auto_increment.columns，某些指标会带这个标签，旧 Dashboard 可能没适配。
为什么迁移后 mysql_up 是 1，但慢查询指标全为 0
mysql_up == 1 只代表 exporter 能连上 MySQL，不代表它能读取所有 performance_schema 表。慢查询、锁等待、IO 统计等指标依赖 performance_schema 开启且对应消费者已启用，迁移时常被忽略。
必须检查 MySQL 侧配置：
- 登录新库执行 SELECT * FROM performance_schema.setup_consumers WHERE NAME LIKE 'events%';，确保 events_statements_history_long、events_waits_current 等关键 consumer 是 ENABLED；
- 检查 performance_schema 是否启用：SHOW VARIABLES LIKE 'performance_schema'; 必须为 ON；
- 若用的是 MySQL 8.0+，确认 setup_actors 允许 exporter 用户采集（默认只允许 'root'@'%'）；
- mysqld_exporter 默认只收集基础指标，要启用慢查询需加参数 --collect.perf_schema.eventsstatements 和 --collect.perf_schema.eventswaits，不加就不会拉这些数据。
迁移不是换地址就完事，exporter 和 MySQL 两端的“能力协商”得重新对齐。最容易被跳过的，就是 performance_schema 的 consumer 开关和 exporter 的 collect 参数组合。
