慢SQL监控核心是定位影响业务稳定性的异常查询，需区分偶发性与持续性风险，结合执行计划、资源消耗、业务上下文及频率趋势多维判断，并按P0/P1级分级动态告警。
慢SQL监控的核心目标
不是单纯发现执行时间长的SQL，而是快速定位影响业务稳定性和用户体验的异常查询。重点在于区分“偶发性慢”和“持续性风险”，避免告警疲劳，同时确保高危SQL（如未走索引、全表扫描、大结果集）不被漏掉。
关键数据采集维度
仅靠执行时间阈值（如 >1s）远远不够。需结合多维指标联合判断：
-
执行计划特征：是否含
type=ALL、rows显著大于实际返回行数、Extra中出现Using filesort或Using temporary -
资源消耗：CPU 时间、逻辑读/物理读次数、临时表使用量（MySQL 的
Created_tmp_tables）、排序次数 - 业务上下文：所属服务名、调用接口、用户ID范围（如是否集中于某类运营活动）、是否在高峰期触发
- 频率与趋势：单条SQL在5分钟内重复出现次数、同比/环比执行耗时增幅 >200%
自动告警触发策略
采用分级+动态阈值方式，兼顾灵敏度与准确性：
- P0级（立即告警）：全表扫描 + 执行时间 >3s + 单次逻辑读 >100万，或同一SQL 10分钟内触发5次以上且平均耗时 >2s
- P1级（聚合告警）：未走索引但耗时
- 抑制机制：对已标记“已优化”的SQL ID 自动静默24小时；对凌晨低峰期的慢查降低一级告警等级
告警信息必须包含的可操作字段
收到告警不能只看“这条SQL慢了”，而要能立刻判断“为什么慢、影响谁、怎么查”：
- 完整SQL文本（脱敏敏感字段，如手机号、身份证号）
- 对应执行计划（
EXPLAIN FORMAT=JSON输出片段） - 最近3次执行的耗时、扫描行数、返回行数对比表格
- 关联应用服务名、主机IP、数据库实例名、慢查发生时间戳（精确到毫秒）
- 一键跳转链接：直达该SQL在监控平台的详情页、或自动打开该实例的Performance Schema分析视图
