mysql如何监控数据库的慢查询峰值_设置慢查询阈值告警

可通过执行SHOW VARIABLES LIKE 'slow_query_log'、'long_query_log_file'、'long_query_time'三条命令确认MySQL慢查询日志是否启用及阈值；默认通常为OFF且long_query_time=10秒，需手动设为ON并调低阈值（如0.5秒）以适配线上需求。如何确认 MySQL 当前慢查询阈值和日志是否启用MySQL 的慢查询监控依赖两个核心配置：是否开启慢查询日志，以及 long_query_time 设为多少。默认多数发行版（如 Percona、官方二进制包）不启用慢查询日志，且 long_query_time 默认是 10 秒------这对线上服务几乎没意义。执行以下命令直接检查：SHOW VARIABLES LIKE 'slow_query_log';<br>SHOW VARIABLES LIKE 'long_query_log_file';<br>SHOW VARIABLES LIKE 'long_query_time';常见错误现象：slow_query_log 显示 OFF；或 long_query_time 是 10，但业务里 500ms 就卡顿。别信"默认已开"，必须手动确认并修改。用 SET GLOBAL slow_query_log = ON 可临时开启，但重启失效；要持久化，得写进 my.cnf 的 [mysqld] 段落long_query_time 支持小数，例如设为 0.5 表示记录超过 500ms 的查询（注意：单位是秒，不是毫秒）MySQL 5.7+ 支持按微秒精度统计（需开启 log_queries_not_using_indexes 配合），但阈值仍以秒为单位为什么不能只靠 slow_query_log 文件做峰值告警慢查询日志是追加写入的文本文件，没有结构化时间戳字段（只有日志行开头的日期，格式还随系统 locale 变），无法直接用 tail -f + awk 精确统计"每分钟新增慢查询数"。更关键的是：日志写入有延迟，且可能被并发刷盘截断，导致漏计或重复计。真实监控场景下，你关心的是"过去 5 分钟内慢查询突增到 200 条/分钟"，而不是"今天总共写了 1289 行日志"。所以必须绕过日志文件，改用性能模式（Performance Schema）或信息模式（INFORMATION_SCHEMA）中的实时指标。MySQL 5.6+ 推荐查 performance_schema.events_statements_summary_by_digest，它聚合了 SQL 模板级的执行统计，含 avg_timer_wait 和 sum_timer_wait，可反推慢查询比例MySQL 8.0+ 可结合 sys.schema_table_statistics_with_buffer 视图快速定位高延迟表，但不直接反映"峰值"避免用 SHOW PROCESSLIST 抓当前慢查询------它只反映瞬时状态，错过就没了，无法支撑趋势告警用 pt-query-digest 实时解析慢日志并输出峰值速率Percona Toolkit 的 pt-query-digest 是目前最靠谱的慢日志分析工具，它能边读日志边统计单位时间内的查询频次，支持 --review-history 写入数据库做趋势对比，也支持 --report-format=profile 输出带时间窗口的汇总。 稿定AI 拥有线稿上色优化、图片重绘、人物姿势检测、涂鸦完善等功能