慢查询告警需与阈值联动实现自动通知、定位与响应：依托performance schema等采集毫秒级指标，在grafana叠加p95基础线、动态告警线和3分钟触发线，并在告警中携带top3 sql、关联指标及跳转链接，支持自动explain分析与轻量闭环处置。
MySQL 慢查询曲线在 Grafana 中展示后，若想让它真正发挥作用，关键在于和阈值告警联动——不是只看图，而是图一“越线”就自动通知、定位、响应。
慢查询指标必须可量化、可采集
Grafana 本身不采集数据，它依赖 MySQL 暴露的指标。常见可靠来源有：
-
Performance Schema（推荐）：启用
events_statements_history_long或按 digest 聚合的events_statements_summary_by_digest，提取AVG_TIMER_WAIT、COUNT_STAR、SUM_ROWS_AFFECTED等字段，单位统一转为毫秒便于设阈值 -
Slow Query Log + pt-query-digest + Prometheus Exporter：用
pt-query-digest --report-format json定时解析日志，再通过自定义 exporter 暴露为 Prometheus 指标（如mysql_slow_query_duration_ms_avg） -
mysqld_exporter 内置指标：开启
--collect.global_status --collect.info_schema.processlist --collect.perf_schema.eventsstatements，但注意默认不暴露单条慢查询耗时，需配合 custom metrics 补充
在 Grafana 中建曲线图并绑定动态阈值
不要只画一条“平均执行时间”线。建议叠加三层：
- 基础线：过去 1 小时同分钟粒度的 P95 耗时（避免被偶发尖刺干扰）
-
告警线：固定阈值（如 2000ms）或动态阈值（如 P95 × 1.8），用
thresholds配置为红色虚线，并在 Tooltip 中显示当前值/阈值比 -
触发线：当连续 3 个点（即 3 分钟）超过阈值，用
transform → reduce → count over time生成布尔序列，在图表底部加一个“告警激活”状态条
告警规则必须带上下文，不能只说“慢了”
Alertmanager 或 Grafana Alerting 触发时，Payload 至少包含：
-
Top 3 慢 SQL digest：从
events_statements_summary_by_digest中取SUM_TIMER_WAIT / COUNT_STAR最高的前三条，附上DIGEST_TEXT截断显示（避免超长） -
关联线索：同一时段的
Threads_running、Innodb_row_lock_time_avg、Created_tmp_disk_tables，判断是锁争用、临时表还是索引缺失 -
快速跳转链接：拼接 ClickHouse 或 Loki 日志查询 URL（如
https://logs.example.com/?query={job="mysql"} |~ "digest:${digest}"），或直接链接到该 SQL 在内部 APM 系统中的调用链
闭环动作建议：自动归因 + 半自动处置
告警不应止于通知。可结合 Webhook 做轻量闭环：
- 收到告警后，调用 Python 脚本自动查
EXPLAIN FORMAT=JSON对应 digest 的典型语句，提取key_len、rows_examined、used_range_check字段，生成优化建议（如“未走索引，建议在 (user_id, status) 上建联合索引”） - 若检测到是重复全表扫描且表小于 500MB，自动触发
ANALYZE TABLE并记录操作日志；若发现Using filesort高频出现，推送消息到 DBA 群并标记“需评估排序字段索引” - 所有动作写入
alert_action_log表，供后续复盘：哪些告警被自动处理，哪些仍需人工介入
不复杂但容易忽略：慢查询告警的价值不在“报得快”，而在“报得准、查得清、动得稳”。指标采集要稳，阈值设定要分场景（比如凌晨批处理允许 5s，而支付接口必须压到 300ms），告警内容要能直接指导下一步动作。
