不能仅靠开启慢查询日志实现有效监控，必须配合pt-query-digest解析日志并用脚本实现阈值告警；需确认slow_query_log=ON、long_query_time≤2.0、log_output=FILE且日志路径权限与空间正常。
不能只靠开启慢查询日志就认为监控到位了——日志本身不带实时计数能力，也不支持阈值告警，必须用 pt-query-digest 搭配外部脚本或监控系统才能落地告警。
确认 MySQL 慢查询日志已正确启用并调低阈值
很多线上环境的 slow_query_log 仍是 OFF，或者 long_query_time 还卡在默认的 10 秒。这会导致大量实际影响业务的查询（比如 800ms 的 JOIN）完全不被记录。
- 执行
SHOW VARIABLES LIKE 'slow_query_log';确认返回值是ON，不是OFF - 执行
SHOW VARIABLES LIKE 'long_query_time';看值是否 ≤2.0（推荐设为1.0或0.5） -
slow_query_log_file路径要有写权限，且磁盘空间充足（避免日志写满导致 MySQL 报错） - 临时生效用
SET GLOBAL slow_query_log = ON;，但必须同步写进my.cnf的[mysqld]段落，否则重启即失效 - 别漏掉
log_output = FILE（MySQL 8.0+ 默认可能是TABLE，而pt-query-digest只读文件）
用 pt-query-digest 实时解析日志并提取峰值速率
pt-query-digest 是目前唯一能稳定从慢日志里算出“每分钟慢查询条数”的工具。它不是简单统计总行数，而是按时间窗口聚合、去重、归一化 SQL 模板后输出频次分布。
- 安装 Percona Toolkit：CentOS 上直接
yum install percona-toolkit；Ubuntu 用apt-get install percona-toolkit - 基础命令：
pt-query-digest --since '2026-05-11 06:00:00' /var/log/mysql-slow.log，可指定起始时间点 - 要获取“最近 5 分钟峰值”，必须配合
--review-histogram和时间范围过滤：pt-query-digest --since "$(date -d '5 minutes ago' +'%Y-%m-%d %H:%M:%S')" /var/log/mysql-slow.log | grep 'Query_time' - 注意：日志路径需与
slow_query_log_file配置完全一致，否则会漏读；如果日志被 logrotate 切分，得加--read-per-process处理多个文件 - 性能影响小，但别在高峰期间用
--filter做复杂正则——会显著拖慢解析速度
用 shell 脚本触发阈值告警并推送消息
把 pt-query-digest 的输出转成数字，再和预设阈值比对，是最轻量、最可控的告警方式。不需要引入 Prometheus 或 Zabbix 就能跑起来。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 核心逻辑：提取
pt-query-digest输出中 “Rank 1” 行的Count字段（即最高频慢查询的执行次数），或用--report-format json解析更稳 - 示例判断逻辑：
count=$(pt-query-digest --since "$(date -d '1 minute ago' +'%Y-%m-%d %H:%M:%S')" /var/log/mysql-slow.log 2>/dev/null | awk '/^# Rank 1/{getline; print $2}') || count=0 - 告警阈值建议设为
10（1 分钟内超 10 条慢查询），高于此值说明有明显毛刺，不是偶发抖动 - 推送可用
curl打企业微信/钉钉 Webhook，或写入本地文件由已有监控系统采集；避免用邮件——延迟高、易被过滤 - 脚本必须加锁（如
flock），防止同一时间多个实例并发解析同一个日志文件导致重复告警
为什么不能用 SHOW STATUS LIKE 'Slow_queries' 做告警
Slow_queries 是一个累计计数器，只增不减。它无法告诉你“过去一分钟新增了多少”，也不能区分是平稳增长还是突发尖峰。
- 执行
SHOW STATUS LIKE 'Slow_queries';返回的是自启动以来的总数，重启后归零 - 两次采样做差值？不行——中间可能重启、主从切换、或日志轮转导致计数器重置，差值不可靠
- 它不区分 SQL 类型，无法定位是某条语句打爆，还是整体负载上升
- 数值更新有延迟，部分版本下甚至 30 秒才刷一次，根本跟不上秒级告警节奏
真正关键的是日志解析的粒度和告警脚本的健壮性——pt-query-digest 的 --since 时间精度、日志轮转策略、以及脚本里对空输出和解析失败的兜底处理，这三处最容易被忽略，却直接决定告警是否准、是否吵。
