干货分享！MySQL慢查询的实践分析总结

MySQL的慢查询，全名是慢查询日志，是MySQL提供的一种日志记录，用来记录在MySQL中响应时间超过阀值的语句。静态我们就来介绍介绍，有需要的可以参考参考。

一 为什么要做这个事情

1 什么是慢SQL？

这里指的是MySQL慢查询，具体指运行时间超过long_query_time值的SQL。

我们常听常见的MySQL中有二进制日志binlog、中继日志relaylog、重做回滚日志redol本文来源gao@daima#com搞(%代@#码@网2og、undolog等。针对慢查询，还有一种慢查询日志slowlog，用来记录在MySQL中响应时间超过阀值的语句。

大家不要被慢查询这个名字误导，以为慢查询日志只会记录select语句，其实也会记录执行时间超过了long_query_time设定的阈值的insert、update等DML语句。

# 查看慢SQL是否开启
show variables like "slow_query_log%";

# 查看慢查询设定的阈值 单位:秒
show variables like "long_query_time";

对于我们使用的AliSQL-X-Cluster即XDB来说，默认慢查询是开启的，long_query_time设置为1秒。

2 慢查询为何会导致故障？

真实的慢SQL往往会伴随着大量的行扫描、临时文件排序或者频繁的磁盘flush，直接影响就是磁盘IO升高，正常SQL也变为了慢SQL，大面积执行超时。

去年双11后，针对技术侧暴露的问题，菜鸟CTO线推出多个专项治理，CTO-D各领一项作为sponsor，我所在的大团队负责慢SQL治理这个专项。

二 要做到什么程度

1 怎么来衡量一个应用的慢SQL严重程度？

微平均

sum(aone应用慢SQL执行次数)
-----------------------
sum(aone应用SQL执行次数)

我们认为，该值越大，影响越大；该值越小，影响可能小。

极端情况就是应用里每次执行的SQL全是慢SQL，该值为1；应用里每次执行的SQL全不是慢SQL，该值为0。

但是这个指标带来的问题是区分度不佳，尤其是对SQL QPS很高且大多数情况下SQL都不是慢查询的情况，偶发的慢SQL会被淹没。

另外一个问题，偶发的慢SQL是真的慢SQL吗？我们遇到很多被慢查询日志记录的SQL，实际上可能受到其他慢SQL影响、MySQL磁盘抖动、优化器选择等原因使得常规查询下表现显然不是慢SQL的变成了慢SQL。

宏平均

sum(慢SQL 1执行次数)    sum(慢SQL n执行次数)
-----------------  +  ------------------
sum(SQL 1执行次数)      sum(SQL n执行次数)
---------------------------------------
                   n

这个算法建立在被抓到的慢SQL有一定执行次数的基础上，可以减少假性慢SQL的影响。

当某些应用QPS很低，即一天执行SQL的次数很少，如果碰到假性SQL就会引起统计误差。

执行次数

sum(aone应用慢SQL执行次数)
-----------------------
           7

统计最近一周平均每天的慢SQL执行次数，可以消除掉宏平均带来的假性SQL问题。

慢SQL模板数量

以上维度均有个时间限定范围，为了追溯慢SQL历史处理情况，我们还引入了全局慢SQL模板数量维度。

count(distinct(aone应用慢SQL模板) )

2 目标

• 核心应用：解决掉所有的慢SQL

• 普通应用：微平均指标下降50%

3 CTO报表

喜欢 (0)赏

[搞代码]

分享 (0)