mysql告警规则必须基于mysqld_exporter实际暴露的指标编写，如用rate(mysql_global_status_slow_queries[5m])判断慢查询速率，而非总量；grafana预警可视化需关联多指标对比（如qps与查询延迟），并配置alertmanager实现精准通知。
能实现图形化预警，但关键不在“能不能”，而在告警规则是否贴合业务真实瓶颈、Grafana仪表盘是否把触发条件可视化出来。
MySQL告警规则必须基于可采集指标写，不能凭空定义
Prometheus本身不生成告警，它靠alertmanager执行alert_rules。所有规则必须对应mysqld_exporter实际暴露的指标，比如：
-
mysql_global_status_threads_connected（当前连接数）——对比max_connections值才有效，直接设“>500”可能误报 -
mysql_global_status_slow_queries（慢查询累计数）——要配合rate(mysql_global_status_slow_queries[5m])算速率，否则只看总量毫无意义 -
mysql_global_status_innodb_row_lock_time_avg（InnoDB平均锁等待时间）——需搭配mysql_global_status_innodb_row_lock_waits一起判断是否真有锁争用
常见错误是抄网上模板直接用mysql_up == 0当数据库宕机告警，但其实mysql_up只是exporter连得上MySQL，不代表业务SQL能执行成功。
Grafana里“预警可视化”不是加个阈值线就完事
真正有用的预警图形，得让值班人一眼看出“为什么触发”。比如：
- 在QPS图上叠加
rate(mysql_global_status_questions[1m])曲线，再画一条95th percentile of query duration的辅助线，当QPS突增+延迟同步跳升，才说明是性能拐点 - 连接数面板不能只画
mysql_global_status_threads_connected，要并列显示mysql_global_status_threads_created（每秒新建连接数），持续高创建率才是泄漏信号 - 缓存命中率必须拆成
mysql_global_status_key_reads / mysql_global_status_key_read_requests和mysql_global_status_innodb_buffer_pool_reads / mysql_global_status_innodb_buffer_pool_read_requests两组，MyISAM和InnoDB缓存机制完全不同
很多人导入社区Dashboard后发现“告警了但看不出原因”，问题常出在这里：图表没把关联指标放在一起比对。
Alertmanager配置决定告警是否真的“可达”
规则写对、图表画准，最后一步是确保通知能落到人手上。生产环境必须检查：
-
route配置里group_by: [alertname, instance]是否合理——把不同MySQL实例的“连接数超限”合并推送，容易漏看具体哪台挂了 -
repeat_interval别设太短，比如1m，否则一个持续问题会刷屏；也别设太长，如4h，错过黄金处理窗口 - 企业微信/钉钉通知模板里必须包含
{{ .Labels.instance }}和{{ .Annotations.description }}，否则收件人打开消息第一反应是“这是谁家库？”
最容易被忽略的是inhibit_rules：比如已触发“MySQL进程离线”告警时，自动抑制所有基于该实例的衍生告警（如“主从延迟>30s”），避免告警风暴冲掉真正要处理的问题。
