MySQL 的慢查询日志（slow_query_log）本身不支持直接触发告警，它只是将执行时间超过 long_query_time 的语句记录到文件或表中。要实现“联动告警”，需借助外部机制对日志内容进行实时监控和分析。
理解 slow_query_log 与 long_query_time 的关系
slow_query_log 是开关，决定是否开启慢查询日志功能；long_query_time 是阈值（单位：秒，支持微秒精度如 0.1），只有执行时间 ≥ 该值的查询才会被记录（前提是满足其他条件，如未使用索引且 log_queries_not_using_indexes 开启）。
注意：
- 该阈值对每个查询单独判断，不统计平均或峰值；
- 设置过低（如 0.01）可能导致日志爆炸，影响性能；
- 建议结合业务响应预期设定，例如接口 P95 响应为 300ms，则可设为 0.3～0.5 秒观察。
常用告警联动方案
以下方式均可与现有运维体系集成（如 Prometheus + Alertmanager、Zabbix、企业微信/钉钉机器人等）：
-
文件轮询 + 日志采集器：启用
slow_query_log_file（默认host-slow.log），用 Filebeat / Fluent Bit 实时采集新写入的慢查询行，通过正则提取耗时、SQL、数据库名等字段，匹配规则后触发告警。 -
查询 mysql.slow_log 表（需开启 log_output='TABLE'）：适合中小流量场景。定时执行 SQL 如
SELECT * FROM mysql.slow_log WHERE start_time > DATE_SUB(NOW(), INTERVAL 1 MINUTE)，脚本解析结果并调用告警接口。 -
Percona Toolkit 工具链：使用
pt-query-digest分析慢日志生成摘要，并配合--notify或自定义脚本输出异常指标（如某类 SQL 出现频次突增、单条耗时破 5s），再交由监控系统处理。
关键配置与验证步骤
确保基础配置生效是告警准确的前提：
- 动态开启：执行
SET GLOBAL slow_query_log = ON;和SET GLOBAL long_query_time = 0.3;（注意：会话级设置无效，必须 GLOBAL） - 确认输出方式：
SET GLOBAL log_output = 'FILE';或'TABLE'；若选 TABLE，需确保mysql.slow_log表存在（首次启用时自动创建） - 验证是否生效：执行一条人为慢 SQL，如
SELECT SLEEP(0.4);，然后检查日志文件末尾或SELECT * FROM mysql.slow_log ORDER BY start_time DESC LIMIT 1; - 避免误报：关闭
log_queries_not_using_indexes（除非专项优化需要），防止全表扫描语句干扰慢查告警焦点
进阶建议：从“告警”走向“预防”
单纯告警是被动响应，更有效的做法是构建闭环：
- 将慢查询日志接入 APM（如 SkyWalking、Pinpoint），关联应用链路，快速定位是 SQL 问题还是上游调用拖慢
- 定期用
pt-query-digest输出 TOP 10 最耗资源 SQL，推动开发添加缺失索引或重构逻辑 - 在 CI/CD 流程中加入 SQL 审核环节，拦截高危写法（如无 WHERE 的 UPDATE、子查询嵌套过深），从源头减少慢查产生
