mysql如何配置慢查询报警_监控指标采集与阈值设置实务-mysql教程-PHP中文网

mysql慢查询告警需结合performance schema实时指标、业务分层阈值和频次过滤，禁用默认slow_query_log=off/long_query_time=10.0配置，按oltp（0.5s）、报表（10.0s）分档设阈值，优先用events_statements_summary_by_digest统计并用redis缓存指纹频次触发告警。

mysql如何配置慢查询报警_监控指标采集与阈值设置实务

MySQL 慢查询告警不能只靠 slow_query_log 文件轮询，必须结合 Performance Schema 实时指标 + 业务分层阈值 + 频次过滤，否则告警全是噪音或漏报。

查当前配置：别信默认值，`SHOW VARIABLES` 必须逐条确认

很多线上库仍维持 slow_query_log = OFF 和 long_query_time = 10.0，这是历史遗留陷阱。执行以下三条命令是第一步：

SHOW VARIABLES LIKE 'slow_query_log'; —— 若返回 OFF，日志根本没开
SHOW VARIABLES LIKE 'long_query_time'; —— 注意：设为 1（整数）会被忽略，必须写 1.0 才生效
SHOW VARIABLES LIKE 'log_output'; —— 若是 FILE，说明只写文件；若含 TABLE，才能查 mysql.slow_log 表（但不推荐依赖此表做实时告警）

临时开启可用 SET GLOBAL slow_query_log = ON，但重启即失效；要持久化，必须写进 my.cnf 的 [mysqld] 段，并重启 mysqld 进程。

设阈值：按业务类型分档，不是统一填个 1.0 就完事

OLTP 场景（如订单、支付）的 long_query_time 建议设为 0.5（500ms），聚合报表类可放宽到 10.0，但需配合 log_queries_not_using_indexes = ON 抓索引缺失问题。关键点：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

同一实例不同库/业务线，应通过 init_connect 或应用层设置会话级 long_query_time（MySQL 5.7+ 支持会话变量）
测试环境建议设为 0.1 或 0（记录所有查询），提前暴露低效 SQL
设为 0 时，日志量剧增，务必配好 log_output = TABLE + 定期清理 mysql.slow_log，避免撑爆系统表空间

采峰值指标：绕过慢日志文件，直取 `performance_schema.events_statements_summary_by_digest`

用 tail -f slow.log | awk 统计每分钟慢查询数，既不准又延迟高。真实监控应查 Performance Schema：

该表中 SUM_TIMER_WAIT 单位是皮秒，除以 10^12 得秒数；COUNT_STAR 是总执行次数
计算“最近 5 分钟慢查询占比”：筛选 AVG_TIMER_WAIT / 10^12 > long_query_time 的 digest 行，再求其 COUNT_STAR 占比
注意：该表默认可能关闭，需确保 setup_consumers 中 events_statements_summary_by_digest 为 ENABLED，且 setup_instruments 开启相关 statement 监控

示例查询（统计平均耗时超 800ms 的 SQL 模板）：

SELECT DIGEST_TEXT, COUNT_STAR, ROUND(AVG_TIMER_WAIT/10^12, 3) avg_sec
FROM performance_schema.events_statements_summary_by_digest
WHERE AVG_TIMER_WAIT > 800000000000
ORDER BY avg_sec DESC LIMIT 5;

告警触发：单次超时不算数，必须叠加频次与趋势

直接对 Slow_queries 状态变量做 increase(slow_queries[5m]) > 10 会误报——它包含所有历史慢查询累计值，且无法区分 SQL 类型。正确做法：

用 Redis 缓存每个 SQL fingerprint（如 MD5(DIGEST_TEXT)）在最近 5 分钟内的触发次数，达到 3 次才告警
同时检查该 fingerprint 的 AVG_TIMER_WAIT 是否连续两个采集周期上涨 >200%，防止毛刺干扰
告警消息里必须带上下文：对应时刻的 SHOW PROCESSLIST 快照、最近 3 次 EXPLAIN FORMAT=JSON 结果、InnoDB 锁等待数，这些数据得在触发瞬间自动采集落库

最易被忽略的一点：告警闭环不只看“是否加了索引”，而要看“优化后 7 日内同一 fingerprint 是否零复发”。重复率超 15%，说明阈值设得太松，或根本没解决执行计划退化问题。