应优先用 performance_schema.events_statements_summary_by_digest 替代 slow_log 表，通过 DIGEST_TEXT 归一化 SQL、AVG_TIMER_WAIT 计算平均耗时、COUNT_STAR 统计频次，并结合 avg_over_time() 告警与正确分母计算慢查占比，确保指标可溯源。
如何让 Grafana 从 MySQL 慢查询日志里实时拉出有效指标
直接读 slow_log 表或解析日志文件是常见做法，但容易卡在权限、格式和延迟上。MySQL 5.7+ 默认关闭 slow_query_log，且 log_output='TABLE' 时，mysql.slow_log 是 CSV 引擎表，不支持索引 —— 查询一多就超时。
- 先确认开启方式：
SET GLOBAL slow_query_log = ON，并设long_query_time = 1（别用 0，会吞掉所有查询） -
log_output推荐设为'FILE'，再用pt-query-digest定期解析日志生成汇总表（如slow_summary_by_digest），Grafana 只查这张表 - 避免直连
mysql.slow_log：它默认无主键、无索引、每行都是 TEXT 字段，Grafana 做GROUP BY或时间范围筛选时极易 OOM - 如果必须用 FILE 输出，确保日志路径对 MySQL 用户可读，且 Grafana 数据源用户有对应文件系统访问权限（比如用 Telegraf + exec 插件中转）
Grafana 中怎么写 SQL 查询才能让慢查询 TopN 不失真
“最慢的 10 条”和“出现最多的 10 类”是两类不同需求，SQL 写法稍错，图表就完全跑偏。尤其当 sql_text 被截断、参数被脱敏后，靠字符串匹配去聚合会漏掉同构查询。
- 用
DIGEST_TEXT（来自performance_schema.events_statements_summary_by_digest）代替原始sql_text：它自动归一化参数，SELECT * FROM users WHERE id = ?和SELECT * FROM users WHERE id = 123算同一类 - TopN 响应时间：查
AVG_TIMER_WAIT / 1000000000000（转成秒），排序前加HAVING COUNT_STAR > 5过滤偶发噪声 - TopN 执行频次：用
COUNT_STAR，但注意first_seen/last_seen时间戳要参与过滤，否则历史冷查询会挤掉近期热点 - 别在 Grafana 查询里用
LIKE '%WHERE%'去筛条件 ——DIGEST_TEXT已标准化，直接分组即可
告警规则里为什么 avg_over_time() 比 rate() 更适合慢查询触发
慢查询不是持续发生的流指标，而是离散事件。用 rate() 会把单次 5 秒查询摊薄成每秒 0.001 次，根本触不到阈值；而 avg_over_time() 能真实反映窗口内平均耗时是否越界。
- 推荐表达式：
avg_over_time(mysql_slow_queries_duration_seconds[15m]) > 2，表示过去 15 分钟平均慢查询耗时超 2 秒 - 避免用
count_over_time()直接数条数 —— 如果某分钟突增 20 条 1.1 秒查询，平均仍低于 2 秒，但已暴露应用层压力，此时应结合max_over_time()补充告警 - MySQL 自身不暴露原生 Prometheus 指标，需通过
mysqld_exporter采集。确认它启用了--collect.global_status --collect.info_schema.processlist，否则mysql_slow_queries_duration_seconds根本不存在 - 告警 label 别只写
instance，加上digest_text（需 exporter 支持--collect.perf_schema.events_statements_digests）才能定位到具体 SQL 模板
为什么 dashboard 里 “慢查询占比” 曲线总跳变、不可信
分母选错是主因。用 com_select + com_update + ... 当总查询量，漏掉了 prepared statement、存储过程调用、甚至 ping 请求；更糟的是，这些状态变量是全局累计值，差值计算受服务重启干扰。
- 正确分母：用
performance_schema.events_statements_summary_global_by_event_name中的COUNT_STAR总和，它包含所有语句类型，且支持按时间窗口重置 - 分子：同源表中
events_statements_summary_by_digest里TIMER_WAIT > 1000000000000（1 秒）的COUNT_STAR求和 - 别在 Grafana 里做除法运算 —— 先在 SQL 层算好
ROUND(100.0 * slow_cnt / total_cnt, 2)，否则浮点精度和空值会让曲线断崖式下跌 - 如果用
mysqld_exporter，它的mysql_global_status_questions是个近似替代，但要注意它不含COM_PING和COM_STMT_PREPARE，误差可能达 15%+
慢查询监控真正难的不是画图，而是让每一行数据都经得起反向溯源 —— 你点开告警里的那条 SQL，得能立刻在 performance_schema 里找到对应 digest、执行计划、锁等待链。这要求从日志采集、指标建模到查询归一，每层都对齐语义，而不是拼凑出一个能动的 dashboard 就算完事。
