慢查询需按业务场景分层设阈值，如报表类10秒、订单查询800ms；告警须叠加频次与趋势判断，并自动采集执行计划、锁等待等上下文；闭环要求工单标注处理动作并验证7日无复发，重复率超15%触发DBA复核。
慢查询识别与阈值设定
慢查询的核心是定义“慢”的标准。不能一刀切设为1秒或5秒，需结合业务场景和数据库负载动态调整。例如，报表类查询因数据量大，合理阈值可设为10秒；而实时订单查询超过800ms就应告警。建议按SQL类型分层设置：聚合类（GROUP BY + 大表JOIN）阈值放宽至15秒，单表主键查询严格控制在300ms内。同时启用MySQL的long_query_time参数并开启log_slow_extra，确保记录执行计划、锁等待、扫描行数等关键字段，为根因分析提供依据。
告警触发与去重机制
单纯按单次超时触发告警易造成噪音。应叠加频次与趋势维度：同一SQL在5分钟内出现3次超阈值，或连续2个采样周期平均耗时上涨200%，才触发一级告警。使用Redis缓存最近1小时的SQL指纹（如去除常量后的标准化语句哈希值）及触发次数，避免重复推送。对已告警且仍在慢的SQL，每2小时升级一次通知级别（企业微信→电话），但同一SQL 24小时内最多升级2次，防止告警疲劳。
关联上下文自动采集
告警消息里必须附带可直接定位问题的信息，而非仅“某SQL变慢”。每次触发时自动抓取：执行时刻的SHOW PROCESSLIST快照、该SQL最近3次的EXPLAIN FORMAT=JSON结果、对应时间段的InnoDB行锁等待统计、以及该时段CPU与Buffer Pool命中率变化曲线。这些数据统一落库归档，并在告警卡片中生成直达链接，点击即可查看对比视图，减少人工排查跳转成本。
闭环反馈与效果评估
告警不是终点，而是优化起点。每个慢查询告警工单需强制填写处理动作：是否加索引、是否改写SQL、是否拆分报表任务，并标记“已验证”——即确认优化后连续7天未再触发同类告警。后台按月统计三类指标：告警总数下降率、平均修复时长、重复告警率（同一SQL30天内再次告警）。若重复率超15%，说明阈值不合理或优化未治本，需自动推送至DBA复核清单。
