必须使用mysqld_exporter v0.15.0+版本，否则无法兼容mysql 8.4的performance_schema表结构变更及新增instrumentation，旧版本会因权限收紧和视图弃用导致采集失败。
mysqld_exporter 必须用 0.15.0+ 版本，否则无法兼容 MySQL 8.4 的 performance_schema 表结构变更。这是你第一步就该确认的事，不是装完再踩坑。
确认 mysqld_exporter 对 MySQL 8.4 的兼容性
MySQL 8.4 默认启用了 performance_schema 中的更多 instrumentation（比如 events_statements_summary_by_digest），而旧版 mysqld_exporter（如 v0.14.x）仍尝试读取已弃用或权限收紧的视图（如 information_schema.PROCESSLIST），直接导致采集失败、日志报 ERROR: Error 1227: Access denied; you need (at least one of) the PROCESS privilege(s) for this operation。
- 必须使用
mysqld_exporterv0.15.0 或更高版本（截至 2026 年 7 月，最新稳定版是 v0.16.1） - 下载地址统一走官方 GitHub Release 页面：
https://github.com/prometheus/mysqld_exporter/releases - 验证方式：启动后访问
http://localhost:9104/metrics，检查是否包含mysql_global_status_threads_connected、mysql_info_schema_table_rows等指标，且无# HELP mysql_.* error类行
MySQL 8.4 用户权限配置不能只给 SELECT
MySQL 8.4 强化了安全模型，默认禁用 PROCESS 权限对普通用户的暴露，而 mysqld_exporter 需要它读取线程状态和慢查询摘要。只给 SELECT 会卡在 mysql_global_status_threads_running 这类基础指标上。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 创建专用监控用户（不要复用 root 或应用账号）：
CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'strong_password_2026';
- 授予权限时必须显式包含：
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';
- 特别注意：MySQL 8.4 要求
REPLICATION CLIENT才能访问performance_schema.replication_connection_configuration（用于主从延迟监控），漏掉会导致mysql_slave_status_seconds_behind_master指标为空 - 执行
FLUSH PRIVILEGES;后，用mysql -u exporter -p -e "SHOW GRANTS;"确认权限已生效
Grafana 仪表盘导入后需手动适配 MySQL 8.4 新指标
社区常用模板（如 ID 11074、12721）基于 MySQL 5.7/8.0 设计，对 MySQL 8.4 新增的指标（如 mysql_info_schema_innodb_buffer_pool_pages_total、mysql_global_status_innodb_deadlocks）默认未启用，面板空白不等于没数据，只是查询语句没匹配上。
- 打开 Grafana → Dashboard → Edit → 每个 Panel → Metrics → 修改 PromQL 查询，例如将：
rate(mysql_global_status_queries[1m])
替换为更稳定的：rate(mysql_global_status_com_select[1m]) + rate(mysql_global_status_com_insert[1m]) + rate(mysql_global_status_com_update[1m]) + rate(mysql_global_status_com_delete[1m]) - 启用 Buffer Pool 命中率新计算方式：
(1 - rate(mysql_global_status_innodb_buffer_pool_reads[1m]) / rate(mysql_global_status_innodb_buffer_pool_read_requests[1m])) * 100 - 慢查询统计应改用 digest 表：
count by (digest_text) (mysql_info_schema_events_statements_summary_by_digest_count{schema=~".+"} > 0)
Prometheus 抓取间隔别设太短，MySQL 8.4 的 performance_schema 开销变大
MySQL 8.4 默认开启更多 performance_schema instrument，单次 mysqld_exporter 抓取耗时比 8.0 高 30%～50%。若 scrape_interval 设为 10s，极易触发 scrape_timeout，造成指标断点或 Prometheus 日志刷屏 context deadline exceeded。
- 生产环境建议设为
scrape_interval: 30s，scrape_timeout: 20s - 如果必须高频采集（如压测分析），优先调低
mysqld_exporter的--collect.perf_schema.eventswaits等非必要收集项，而不是硬压间隔 - 观察
prometheus_target_scrapes_duration_seconds的 P99 值，持续 >15s 就该优化 exporter 配置或 MySQL 参数
MySQL 8.4 的 performance_schema 是活的，不是静态快照——它的开销、权限边界、表结构都在变。所有配置都要以它为基准校准，而不是沿用旧文档里的“标准做法”。
