慢 SQL 治理分享

一 为什么要做这个事情

1 什么是慢SQL？

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

我们常听常见的MySQL中有二进制日志binlog、中继日志relaylog、重做回滚日志redolog、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有一定执行次数的基础上&#x