监控数据库慢查询频次需避开日志解析瓶颈，优先采用Performance Schema实时聚合统计或pt-query-digest流式分析，辅以调低long_query_time至0.5秒并持久化配置。
监控数据库慢查询频次，核心是绕开原始日志文件的解析瓶颈，转向实时、可聚合、带时间维度的指标采集。直接 tail + awk 统计 slow.log 不可靠——日志无结构化时间戳、写入延迟、并发截断易漏计，无法支撑“每分钟新增 150 条慢查询”这类业务告警需求。
确认并调低慢查询阈值
很多线上环境仍用默认 long_query_time = 10 秒，但用户感知卡顿往往在 500ms 内。必须手动调整：
- 执行
SHOW VARIABLES LIKE 'slow_query_log'确认是否开启（OFF 就得先开） - 执行
SHOW VARIABLES LIKE 'long_query_time'查当前阈值，建议设为 0.5（单位是秒，不是毫秒） -
SET GLOBAL slow_query_log = ON可临时启用，但要持久化，必须写入 my.cnf 的 [mysqld] 段落
用 Performance Schema 实时统计频次
MySQL 5.6+ 提供 performance_schema.events_statements_summary_by_digest，它按 SQL 模板聚合执行数据，含 COUNT_STAR 和 SUM_TIMER_WAIT，可反推单位时间内的慢查询发生次数：
- 定期（如每分钟）查询该表，筛选
SUM_TIMER_WAIT / COUNT_STAR > 阈值 * 1000000000（纳秒单位）的语句 - 对比前后两次的
COUNT_STAR差值，即为该模板在该分钟内执行次数 - 再结合业务逻辑标记“慢”的条件（例如平均耗时超 500ms 或单次超 1s），即可算出真实慢查询频次
用 pt-query-digest 边读边统计峰值
Percona Toolkit 的 pt-query-digest 是目前最稳的方案，它不依赖日志写完再分析，而是流式读取并滚动统计：
- 命令示例：
pt-query-digest --print --no-report --filter '$event->{Query_time} > 0.5' --group-by fingerprint /var/lib/mysql/slow.log - 配合
--since和--until参数，可精确提取过去 5 分钟的日志片段 - 输出中 Rank 列对应出现频次，Query_time 的 median 和 95% 值能反映稳定性
避免三个常见误区
有些做法看似简单，实则无效或危险：
- 不用 SHOW PROCESSLIST 抓“当前慢查询”：它只拍快照，漏掉已结束但耗时长的查询
- 不依赖 Slow_queries 状态变量：它只是累加总数，无法拆解到分钟级趋势
- 不硬解析 slow.log 行首时间戳：locale 不同导致格式不一致（如 “# Time: 240312 10:22:33” vs “# Time: 2024-03-12T10:22:33”），正则易失效
